Cloud CPE Centralized Deployment Model

(1)

Deployment Guide

(2)

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.0

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 2038. However, the NTP application is known to have some difficulty in the year 2036.

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

(3)

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 . . . 15

Cloud CPE Centralized Deployment Model Overview . . . 16

VNFs Supported by the Cloud CPE Centralized Deployment Model . . . 16

NFV in the Cloud CPE Centralized Deployment Model . . . 17

Architecture of the Cloud CPE Centralized Deployment Model . . . 20

Benefits of the Cloud CPE Centralized Deployment Model . . . 23

Licensing for the Cloud CPE Centralized Deployment Model . . . 24

Hardware and Software Tested in the Cloud CPE Centralized Deployment Model . . . 24

Chapter 2 Installing and Configuring the Hardware and Software Components . . . . 27

Minimum Hardware and Software Requirements for Servers and VMs . . . 27

Cabling the Hardware for the Cloud CPE Centralized Deployment Model . . . 29

Configuring the EX Series Ethernet Switch . . . 31

Configuring the QFX Series Switch . . . 32

Configuring the MX Series Router . . . 34

Setting Up the VMs for the Contrail Service Orchestration Node . . . 36

Deploying the Cloud CPE Centralized Deployment Model Installer . . . 38

Installing and Configuring the Cloud CPE Centralized Deployment Model . . . 39

Installing Contrail OpenStack . . . 39

Customizing the Configuration File for the Cloud CPE Centralized Deployment Model Installation . . . 39

Deploying the Cloud CPE Centralized Deployment Model . . . 44

Configuring Contrail for the Cloud CPE Centralized Deployment Model . . . 45

Configuring a Junos Space Cluster . . . 45

Creating an LxCIPtable VNF Image . . . 46

Chapter 3 Setting Up and Managing the Cloud CPE Centralized Deployment Model . . . 49

Setting Up the NFV Infrastructure for the Cloud CPE Centralized Deployment Model . . . 49

Adding Customers to the Cloud CPE Centralized Deployment Model . . . 52

(4)

Chapter 4 Using the Cloud CPE Centralized Deployment Model . . . 59

Working with Network Services in the Centralized Deployment Model . . . 59

Customer Access to Network Services . . . 59

Chapter 5 Troubleshooting the Cloud CPE Centralized Deployment Model . . . 61

Monitoring and Troubleshooting Overview . . . 61

Chapter 6 Appendix—Terminology . . . 63

(5)

Chapter 1 Overview of Cloud CPE Centralized Deployment Model . . . 15 Figure 1: Software Components of the Cloud CPE Centralized Deployment

Model . . . 18 Figure 2: Topology of Cloud CPE Centralized Deployment Model with CCRA and

(6)

(7)

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 . . . 15

Table 3: Cloud CPE Centralized Deployment Model Licenses . . . 24

Table 4: Network Devices Tested in the Cloud CPE Centralized Deployment Model . . . 24

Table 5: Specification of Servers Tested for Cloud CPE Centralized Deployment Model . . . 25

Table 6: Software Used in Cloud CPE Centralized Deployment Model . . . 25

Chapter 2 Installing and Configuring the Hardware and Software Components . . . . 27

Table 7: Minimum Hardware Requirements for Servers in Cloud CPE Centralized Deployment Model . . . 27

Table 8: Software Requirements for Cloud CPE Centralized Deployment Model . . . 28

Table 9: Connections for EX Series Switch . . . 29

Table 10: Connections for QFX Series Switch . . . 30

Table 11: Connections for MX Series Router . . . 30

Table 12: Software Requirements for VMs on Contrail Service Orchestration Server . . . 36

Chapter 3 Setting Up and Managing the Cloud CPE Centralized Deployment Model . . . 49

Table 13: Options for Python allow_all_ingress.py File . . . 58

Chapter 6 Appendix—Terminology . . . 63

(8)

(9)

• Documentation and Release Notes on page ix

• Documentation Conventions on page ix

• Documentation Feedback on page xi

• Requesting Technical Support on page xii

Documentation and Release Notes

To obtain the most current version of all Juniper Networks®technical documentation, see the product documentation page on the Juniper Networks website at

http://www.juniper.net/techpubs/.

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 athttp://www.juniper.net/books.

Documentation Conventions

(10)

Table 1: Notice Icons

Description Meaning

Icon

Indicates important features or instructions. Informational note

Indicates a situation that might result in loss of data or hardware damage. Caution

Alerts you to the risk of personal injury or death. Warning

Alerts you to the risk of personal injury from a laser. Laser warning

Indicates helpful information. Tip

Alerts you to a recommended use or implementation. Best practice

Table 2 on page xdefines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Examples Description

Convention

To enter configuration mode, type the configure command:

user@host> configure Represents text that you type.

Bold text like this

user@host> show chassis alarms No alarms currently active Represents output that appears on the

terminal screen. Fixed-width text like this

• A policy term is a named structure that defines match conditions and actions.

• Junos OS CLI User Guide

• RFC 1997, BGP Communities Attribute

• Introduces or emphasizes important new terms.

• Identifies guide names.

• Identifies RFC and Internet draft titles. Italic text like this

Configure the machine’s domain name: [edit]

root@# set system domain-name domain-name

Represents variables (options for which you substitute a value) in commands or configuration statements.

(11)

Table 2: Text and Syntax Conventions (continued)

Examples Description

Convention

• To configure a stub area, include the stubstatement at the[edit protocols ospf area area-id]hierarchy level.

• The console port is labeledCONSOLE. Represents names of configuration

statements, commands, files, and directories; configuration hierarchy levels; or labels on routing platform

components. Text like this

stub <default-metric metric>; Encloses optional keywords or variables.

< > (angle brackets)

broadcast | multicast

(string1 | string2 | string3) 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. | (pipe symbol)

rsvp { # Required for dynamic MPLS only Indicates a comment specified on the

same line as the configuration statement to which it applies.

# (pound sign)

community name members [ community-ids ]

Encloses a variable for which you can substitute one or more values. [ ] (square brackets) [edit] routing-options { static { route default { nexthop address; retain; } } } Identifies a level in the configuration

hierarchy. Indention and braces ( { } )

Identifies a leaf statement at a configuration hierarchy level. ; (semicolon)

GUI Conventions

• In the Logical Interfaces box, select All Interfaces.

• To cancel the configuration, click Cancel.

Represents graphical user interface (GUI) items you click or select.

Bold text like this

In the configuration editor hierarchy, select Protocols>Ospf.

Separates levels in a hierarchy of menu selections.

> (bold right angle bracket)

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:

(12)

• E-mail—Send your comments to [email protected]. 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

http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/.

• 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:http://www.juniper.net/customers/support/

• Search for known bugs:http://www2.juniper.net/kb/

• Find product documentation:http://www.juniper.net/techpubs/

• Find solutions and answer questions using our Knowledge Base:http://kb.juniper.net/

• Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:

http://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/

• Open a case online in the CSC Case Management tool:http://www.juniper.net/cm/

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:https://tools.juniper.net/SerialNumberEntitlementSearch/

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 athttp://www.juniper.net/cm/.

(13)

For international or direct-dial options in countries without toll-free numbers, see

(14)

(15)

Deployment Model

• Cloud CPE Centralized Deployment Model Overview on page 16

• VNFs Supported by the Cloud CPE Centralized Deployment Model on page 16

• NFV in the Cloud CPE Centralized Deployment Model on page 17

• Architecture of the Cloud CPE Centralized Deployment Model on page 20

• Benefits of the Cloud CPE Centralized Deployment Model on page 23

• Licensing for the Cloud CPE Centralized Deployment Model on page 24

• Hardware and Software Tested in the Cloud CPE Centralized Deployment

(16)

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) are located in a central cloud in a 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 the central cloud to obtain network services. 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.

VNFs Supported by the Cloud CPE Centralized Deployment Model

The Cloud CPE Centralized Deployment Model supports the following VNFs, which reside in the VNF catalog.

• Carrier-Grade Network Address Translation (CGNAT), Firewall, Unified Threat Management (UTM), and a demonstration version of Deep Packet Inspection (DPI) through vSRX.

• NAT and Firewall through the LxCIPTable VNF. This third -party VNF is free and operates in Linux Containers in the Linux kernel.

Cloud CPE Centralized Deployment Model Overview on page 16

•

(17)

NFV in the Cloud CPE Centralized Deployment Model

The Cloud customer premises equipment (CPE) Centralized Deployment Model uses a microservice architecture, which is a distributed, non-hierarchical framework in which multiple software components—microservices—interact to perform the functions of the deployment. Each software component operates independently to implement a set of focused, related functions. The Cloud CPE Centralized Deployment Model uses the following software 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, whichprovides 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 network orchestration (MANO) activities in the deployment. Contrail Service Orchestration consists of the following components:

• Administration CLI, which is a tool that you use to manage customers.

• 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 graphical user interface (GUI). The Customer Portal application uses the RESTful API.

• 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 VNF.

(18)

Figure 1: Software Components of the Cloud CPE Centralized Deployment

Model

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.

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.

(19)

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 provided by Contrail Cloud Platform. Contrail Cloud Platform creates one VM for each VNF in the service chain.

• VNF Manager starts managing the VNF instances and, in the case of the vSRX, the Junos Space Virtual Appliance provides element management.

5. The network service is activated for the customer.

(20)

Architecture of the Cloud CPE Centralized Deployment Model

The Cloud CPE Centralized Deployment Model uses the Contrail Cloud Reference Architecture (CCRA) to support the service provider’s cloud. The CCRA consists of the hardware platforms, including the servers, and Contrail OpenStack software. The Contrail Service Orchestration software is installed on a server in the CCRA to complete the deployment model (Figure 2 on page 20).

Figure 2: Topology of Cloud CPE Centralized Deployment Model with

CCRA and Contrail Service Orchestration

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.

(21)

• Contrail Service Orchestration node

• Contrail configure and control node

• Two Contrail compute nodes

• Up to four additional servers, each with four nodes, act as additional Contrail compute nodes.

• The Cloud CPE Centralized Deployment Model installer and its associated configuration file reside together in a shared VM that is on a server separate from the Cloud CPE Deployment Model server cluster.

Figure 3 on page 21shows the architecture of the Contrail Cloud Platform nodes.

Figure 3: Architecture of Contrail Cloud Platform Nodes

• The configure and control node hosts Contrail, OpenStack, and the VNFs. Contrail and OpenStack reside on the physical server and cannot be deployed in a VM. Each VNF resides in its own VM.

• Each compute 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.

(22)

Figure 4: Contrail Service Orchestration Node

The Contrail Service Orchestration Node supports multiple VMs:

• The following components reside together in a shared VM:

• Network Service Orchestrator

• VNF Manager

• Notification Engine

• Cloud CPE Tenant, Site and Service Manager

• Identity and Access Manager

• Network Service Designer and Customer Portal reside in a shared VM.

• Custom Contrail resides in a dedicated VM.

(23)

The two virtual appliances and their respective databases provide high availability of the element management system.

• Two instances of Service and Infrastructure Monitor both reside in dedicated VMs.

• The Service and Infrastructure Monitor Controller and the Load Balancer reside in a shared VM.

These components work with the two instances of Service and Infrastructure Monitor to provider high availability of the software components.

After you have installed and configured the hardware in the Cloud CPE Centralized Deployment Model, you run a deployment script to install and configure software components and VMs. Depending on the virtual environment, you may need to complete some manual configuration.

Deploying the Cloud CPE Centralized Deployment Model Installer on page 38

•

• Installing and Configuring the Cloud CPE Centralized Deployment Model on page 39

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.

(24)

•

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. SeeTable 3 on page 24.

Table 3: Cloud CPE Centralized Deployment Model Licenses

Number of Junos Space Network

Management Platform Licenses Required Number of Contrail Cloud Platform

Licenses Included Number of VNFs Supported 2 1 2000 8 5 10,000 18 13 25,000 34 25 50,000

Individual Contrail Service Orchestration licenses and Contrail Cloud Platform licenses can be purchased separately. Contrail Service Orchestration licenses are also based on VNF capacity.

•

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 inTable 4 on page 24

• The servers described inTable 5 on page 25

• The software described inTable 6 on page 25

Table 4: Network Devices Tested in the Cloud CPE Centralized Deployment Model

Quantity Model Device Function 1 MX80-48T with two 10 GE XFP optics Juniper Networks MX Series 3D

(25)

Table 4: Network Devices Tested in the Cloud CPE Centralized Deployment Model (continued)

Quantity Model Device Function 1 EX3300-48T with:

• Forty eight 10/100/1000 GE interfaces

• Four built-in 10 GE SFP interfaces Juniper Networks EX Series Ethernet

Switch Management switch

1 QFX 5100-48S-AFI with:

• Forty eight SFP+ interfaces

• Six QSFP+ interfaces Juniper Networks QFX Series Switch

Data switch

At least 2, up to 5 SeeTable 5 on page 25

Quanta QuantaPlex T41S-2U 2U 4-Node server

Servers

The Cloud CPE Centralized Deployment Model was tested on servers with the specifications shown inTable 5 on page 25.

Table 5: Specification of Servers Tested for Cloud CPE Centralized Deployment Model

Quantity

Model Function

At least 2, up to 5 QuantaPlex T41S-2U 2U 4-Node server with

2.5" drive bay Base server 2 E5-2670 v3 CPU 16 256GB DDR4 2133 MHz

16 GB DIMMs—slots fully populated Memory

5 2.5" 1TB SATA Enterprise

Hard disk drive

1 Intel DC S3700 series 400GB SATA

Solid state drive

1 Large scale integration (LSI) SAS controller 9200-8e card

Controller card

1 Dual port 10 GE SFP+ OCP mezzanine card Interface card

1 Dual port 1 GE mezzanine card

Interface card

2 1600 W high efficiency redundant power supply

Power supply unit (PSU)

(26)

Table 6: Software Used in Cloud CPE Centralized Deployment Model (continued)

Software and Version

Function

Junos OS Release 14.2R3 Operating system for MX Series router

Junos OS Release 12.3R10 Operating system for EX Series switch

Junos OS Release 13.2X51-D38 Operating system for QFX Series switch

Junos Space Network Management Platform, Release 15.1R1

Operating system for Junos Space Virtual Appliance

Contrail 2.21 Software-defined networking (SDN)

OpenStack Icehouse Virtualized infrastructure manager (VIM) and virtual machine (VM)

orchestration

Contrail Service Orchestration 1.0 Network Functions Virtualization (NFV)

(27)

and Software Components

• Minimum Hardware and Software Requirements for Servers and VMs on page 27

• Cabling the Hardware for the Cloud CPE Centralized Deployment Model on page 29

• Configuring the EX Series Ethernet Switch on page 31

• Configuring the QFX Series Switch on page 32

• Configuring the MX Series Router on page 34

• Setting Up the VMs for the Contrail Service Orchestration Node on page 36

• Deploying the Cloud CPE Centralized Deployment Model Installer on page 38

• Installing and Configuring the Cloud CPE Centralized Deployment Model on page 39

• Configuring Contrail for the Cloud CPE Centralized Deployment Model on page 45

• Configuring a Junos Space Cluster on page 45

• Creating an LxCIPtable VNF Image on page 46

Minimum Hardware and Software Requirements for Servers and VMs

The Cloud CPE Centralized Deployment Model runs on commercial off-the-shelf (COTS) x86 servers. When 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 27shows 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

Quantity Requirement

Function

At least 2, up to 5 x86 server with 4 nodes

(28)

Table 7: Minimum Hardware Requirements for Servers in Cloud CPE Centralized Deployment

Model (continued)

Quantity Requirement Function 2 Type Intel Sandybridge, such as Intel Xeon E5-2670v2 @ 2.5 Ghz CPUs – 256 GB per server Memory 5 1 TB, Serial Advanced Technology Attachment (SATA) or Serial Attached SCSI (SAS)

Hard disk drive (HDD)

1 or more 200 GB

Solid-state drive (SSD)

2 10 Gigabit Ethernet (GE) interface on PCIe adaptor or

mezzanine card Data and Control interface

2 1 GE interface

Management Interface

1 Intelligent Platform Management Interface (IPMI)

Out-of-Band Interface

Table 8 on page 28lists the software requirements for the servers.

Table 8: Software Requirements for Cloud CPE Centralized Deployment Model

Version

Description

Ubuntu 14.04 LTS Operating system for server and VMs

Contrail 2.20 with OpenStack (Icehouse), or VMware ESXi Version 5.5.0 Hypervisor on Contrail Service Orchestration

node

Secure File Transfer Protocol (SFTP) Additional software (only required for Contrail

Service Orchestration node)

• Disable DHCP servers on the subnet on which you install the Cloud CPE Centralized Deployment Model. The installer deploys and configures DHCP servers.

• 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.

Additional requirements

Architecture of the Cloud CPE Centralized Deployment Model on page 20

•

• Hardware and Software Tested in the Cloud CPE Centralized Deployment Model on

(29)

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. SeeTable 9 on page 29for information about the connections for the EX Series switch.

2. Connect cables from the QFX Series switch to the other devices in the network.

SeeTable 10 on page 30for information about the connections for the QFX Series

switch.

3. Connect cables from the MX Series router to the other devices in the network. SeeTable 11 on page 30for information about the connections for the MX Series router.

Table 9: Connections for EX Series Switch

Interface on Destination Device Destination Device

Interface on EX Series Switch

ge-0/0/41 EX Series switch

eth0 (management interface)

IPMI Server 1 ge-0/0/0 IPMI Server 2 ge-0/0/1 IPMI Server 3 ge-0/0/2 IPMI Server 4 ge-0/0/3 IPMI Server 5 ge-0/0/4 eth0 Server 1 ge-0/0/20 eth0 Server 2 ge-0/0/21 eth0 Server 3 ge-0/0/22 eth0 Server 4 ge-0/0/23 eth0 Server 5 ge-0/0/24

eth0 (management interface) EX Series switch

ge-0/0/41

eth0 (management interface) QFX Series switch

ge-0/0/42

fxp0 MX Series router

(30)

Table 9: Connections for EX Series Switch (continued)

Interface on EX Series Switch

ge-1/3/11 MX Series router ge-0/0/46 eth1 Server 1 ge-0/0/47

Table 10: Connections for QFX Series Switch

Interface on QFX Series Switch

ge-0/0/42 EX Series switch

eth0 (management interface)

eth2 Server 1 xe-0/0/0 eth2 Server 2 xe-0/0/1 eth2 Server 3 xe-0/0/2 eth2 Server 4 xe-0/0/3 eth2 Server 5 xe-0/0/4 eth3 Server 1 xe-0/0/20 eth3 Server 2 xe-0/0/21 eth3 Server 3 xe-0/0/22 eth3 Server 4 xe-0/0/23 eth3 Server 5 xe-0/0/24 xe-0/0/0 MX Series router xe-0/0/46 xe-0/0/1 MX Series router xe-0/0/47

Table 11: Connections for MX Series Router

Interface on Destination Device

Destination Device Interface on MX Series Router

(31)

Table 11: Connections for MX Series Router (continued)

Interface on Destination Device

Destination Device Interface on MX Series Router

– Service provider’s device at the cloud ge-1/0/0 and ge-1/0/1 or xe-0/0/2 and

xe-0/0/3, depending on the network

•

Configuring the EX Series Ethernet Switch

Before you configure the EX Series switch, complete any basic setup procedures and install the correct Junos OS software release on the switch.

To configure the EX Series switch:

1. Define VLANs for the IPMI ports. For example:

user@switch# set interfaces interface-range ipmi member-range ge-0/0/0 to ge-0/0/19

user@switch# set interfaces interface-range ipmi unit 0 family ethernet-switching port-mode access

user@switch# set interfaces interface-range ipmi unit 0 family ethernet-switching vlan members ipmi

user@switch# set interfaces vlan unit 60 family inet address 172.16.60.254/24 user@switch# set vlans ipmi vlan-id 60

user@switch# set vlans ipmi l3-interface vlan.60

2. Define a VLAN for the management ports. For example:

user@switch# set interfaces interface-range mgmt member-range ge-0/0/20 to ge-0/0/46

user@switch# set interfaces interface-range mgmt unit 0 family ethernet-switching port-mode access

user@switch# set interfaces interface-range mgmt unit 0 family ethernet-switching vlan members mgmt

user@switch# set interfaces vlan unit 70 family inet address 172.16.70.254/24 user@switch# set vlans mgmt vlan-id 70

user@switch# set vlans mgmt l3-interface vlan.70

3. Define a static route for external network access. For example:

user@switch# set routing-options static route 0.0.0.0/0 next-hop 172.16.70.253

Hardware and Software Tested in the Cloud CPE Centralized Deployment Model on page 24

•

(32)

Configuring the QFX Series Switch

Before you configure the QFX Series switch, complete any basic setup procedures and install the correct Junos OS software release on the switch.

To configure the QFX Series switch:

1. Configure the IP address of the Ethernet management port. For example: user@switch# set interfaces vme unit 0 family inet address 172.16.70.251/24

2. Configure integrated routing and bridging (IRB). For example:

user@switch# set interfaces irb unit 80 family inet address 172.16.80.254/24

3. Configure a link aggregation group (LAG) for each pair of server ports. For example: user@switch# set interfaces xe-0/0/0 ether-options 802.3ad ae0

user@switch# set interfaces xe-0/0/20 ether-options 802.3ad ae0 user@switch# set interfaces ae0 mtu 9192

user@switch# set interfaces ae0 aggregated-ether-options lacp active user@switch# set interfaces ae0 aggregated-ether-options lacp periodic fast user@switch# set interfaces ae0 unit 0 family ethernet-switching interface-mode

access

user@switch# set interfaces ae0 unit 0 family ethernet-switching vlan members data user@switch# set interfaces xe-0/0/1 ether-options 802.3ad ae1

access

(33)

user@switch# set interfaces ae4 unit 0 family ethernet-switching interface-mode access

access

user@switch# set interfaces ae8 unit 0 family ethernet-switching vlan members data

4. Configure a VLAN for data transmission. For example: user@switch# set vlans data vlan-id 80

user@switch# set vlans data l3-interface irb.80

5. Configure OSPF routing. For example:

user@switch# set interfaces irb unit 80 family inet address 172.16.80.254/24 user@switch# set protocols ospf area 0.0.0.0 interface irb.80 passive

(34)

•

• Configuring the MX Series Router on page 34

Configuring the MX Series Router

Before you configure the MX Series router, complete any basic setup procedures and install the correct Junos OS software release on the switch.

To configure the MX Series router:

1. Configure interfaces, IP addresses, and basic routing settings. For example: user@router# set interfaces ge-1/0/0 unit 0 family inet address 10.87.24.77/28 user@router# set interfaces lo0 unit 0 family inet address 172.16.100.1/32 user@router# set routing-options route-distinguisher-id 172.16.100.1 user@router# set routing-options autonomous-system 64512 user@router# set protocols ospf area 0.0.0.0 interface lo0.0

user@router# set interfaces ge-1/0/0 unit 0 family inet service input service-set s1 service-filter ingress-1

user@router# set interfaces ge-1/0/0 unit 0 family inet service output service-set s1 service-filter ingress-1

2. Configure the interfaces that connect to the QFX Series switch. For example: user@router# set chassis aggregated-devices ethernet device-count 2 user@router# set interfaces xe-0/0/0 gigether-options 802.3ad ae0 user@router# set interfaces xe-0/0/1 gigether-options 802.3ad ae0

user@router# set interfaces ae0 aggregated-ether-options lacp periodic fast user@router# set interfaces ae0 unit 0 family inet service input service-set s1

service-filter ingress-1

user@router# set interfaces ae0 unit 0 family inet service output service-set s1 service-filter ingress-1

user@router# set interfaces ae0 unit 0 family inet address 172.16.10.254/24 user@router# set protocols ospf area 0.0.0.0 interface ae0.0

3. Configure BGP and tunneling for the service provider’s cloud. For example: user@router# set chassis fpc 0 pic 0 tunnel-services

user@router# set chassis fpc 0 pic 0 inline-services bandwidth 1g

user@router# set routing-options dynamic-tunnels dynamic_overlay_tunnels source-address 172.16.100.1

user@router# set routing-options dynamic-tunnels dynamic_overlay_tunnels gre user@router# set routing-options dynamic-tunnels dynamic_overlay_tunnels

destination-networks 172.16.80.0/24 user@router# set protocols mpls interface all

user@router# set protocols bgp group Contrail_Controller type internal

user@router# set protocols bgp group Contrail_Controller local-address 172.16.100.1 user@router# set protocols bgp group Contrail_Controller keep all

(35)

user@router# set protocols ospf export leak-default-only

4. Set up routing. For example:

user@router# set routing-options static rib-group inet-to-public

user@router# set routing-options static route 0.0.0.0/0 next-hop 10.87.24.78 user@router# set routing-options static route 0.0.0.0/0 retain

user@router# set routing-options static route 10.87.24.64/26 next-table public.inet.0 user@router# set routing-options rib-groups inet-to-public import-rib inet.0

user@router# set routing-options rib-groups inet-to-public import-rib public.inet.0 user@router# set routing-options rib-groups inet-to-public import-policy

leak-default-only

user@router# set policy-options policy-statement leak-default-only term default from route-filter 0.0.0.0/0 exact

user@router# set policy-options policy-statement leak-default-only term default then accept

user@router# set policy-options policy-statement leak-default-only then reject user@router# set routing-instances public instance-type vrf

user@router# set routing-instances public interface lo0.10

user@router# set routing-instances public vrf-target target:64512:10000 user@router# set routing-instances public vrf-table-label

user@router# set routing-instances public routing-options static route 10.87.24.64/26 discard

5. Configure NAT. For example:

user@router# set services service-set s1 nat-rules rule-napt-zone

user@router# set services service-set s1 interface-service service-interface si-0/0/0.0 user@router# set services nat pool contrailui address 10.87.24.81/32

user@router# set services nat pool openstack address 10.87.24.82/32 user@router# set services nat pool jumphost address 10.87.24.83/32

user@router# set services nat rule rule-napt-zone term t1 from source-address 172.16.80.2/32

user@router# set services nat rule rule-napt-zone term t1 then translated source-pool openstack

user@router# set services nat rule rule-napt-zone term t1 then translated translation-type basic-nat44

user@router# set services nat rule rule-napt-zone term t2 then translated source-pool contrailui

user@router# set services nat rule rule-napt-zone term t3 then translated source-pool jumphost

user@router# set firewall family inet service-filter ingress-1 term t1 from source-address 172.16.80.2/32

user@router# set firewall family inet service-filter ingress-1 term t1 from protocol tcp user@router# set firewall family inet service-filter ingress-1 term t1 from

destination-port-except 179

(36)

user@router# set firewall family inet service-filter ingress-1 term t2 then service user@router# set firewall family inet service-filter ingress-1 term t3 from source-address

172.16.70.1/32

user@router# set firewall family inet service-filter ingress-1 term t3 then service user@router# set firewall family inet service-filter ingress-1 term end then skip

•

Setting Up the VMs for the Contrail Service Orchestration Node

You must complete this procedure for the Contrail Orchestration node if you:

• Use a hypervisor other than Contrail Openstack.

• Already have VMs that you want to use.

If you use the Contrail OpenStack hypervisor and have not yet created VMs, the installer creates the VMs with the required resources and opens the required ports.

To set up the Contrail Service Orchestration node:

1. On the Contrail Service Orchestration node, create 10 VMs with the resources listed inTable 12 on page 36.

2. Record the hostnames of the VMs.

You must specify the hostnames in the configuration file.

3. If MySQL software is installed in the VMs for Service and infrastructure Monitor, remove it.

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.

4. Open the required ports on each VM. SeeTable 12 on page 36.

Table 12: Software Requirements for VMs on Contrail Service Orchestration Server

Ports to Open Resources Required

Number of VMs Applications Installer Places in VM

• 4505 • 4506 • 5000 • 6543 • 8006 • 9788 • 8 vCPUs • 32 GB RAM

• 100 GB hard disk storage 1

• Cloud CPE Tenant, Site and Service Manager

• Identity and Access Manager

• Network Service Orchestrator

• Notification Engine

(37)

Table 12: Software Requirements for VMs on Contrail Service Orchestration Server (continued)

Ports to Open Resources Required

Number of VMs Applications Installer Places in VM

• 80 • 4505 • 4506 • 8090 • 8091 • 9200 • 9300 • 4 vCPUs • 8 GB RAM

• Customer Portal

• Network Service Designer

None

• 4 vCPUs

• 24 GB RAM

Junos Space Virtual Appliance

None

• 4 vCPUs

• 24 GB RAM

Junos Space database

None

• 4 vCPUs

• 32 GB RAM

Custom Contrail

None

• 4 vCPUs

• 16 GB RAM

• Service and Infrastructure Monitor Controller

Load Balancer

None

• 4 vCPUs

• 32 GB RAM

• 100 GB hard disk storage

• CAUTION: Make sure that MySQL software is not installed in the VM for 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.

2 Service and Infrastructure Monitor

You can reimage the operating systems on the physical servers when you run the installer to deploy the NFV solution. Doing so ensures that you are running the Ubuntu image included with the installer on both servers. The installer does not reimage the operating system in the VMs, however.

Minimum Hardware and Software Requirements for Servers and VMs on page 27

•

(38)

Deploying the Cloud CPE Centralized Deployment Model Installer

Before you deploy the installer:

1. Create a VM on a server that is separate from the server cluster in the Cloud CPE Centralized Deployment Model with the following resources:

• 6 vCPUs

• 10 GB RAM

• 100 GB hard disk storage

2. Open the following ports on the VM.

• 4505

• 4506

To deploy the installer:

1. Log in to the installer VM as root.

The current directory is the home directory.

2. Copy the installer package to this directory.

3. Expand the package.

root@host:~/# tar –xvf csp-1.0.tar 4. Set up the installer.

root@host:~/# cd csp-1.0 root@host:~/csp-1.0# ./setup.sh

Setting up the installer deploys the following applications:

• Contrail Server Manager, which deploys Contrail Cloud Platform

• Salt Master, which deploys other components in the Cloud CPE Centralized Deployment Model

Installing and Configuring the Cloud CPE Centralized Deployment Model on page 39

•

(39)

Installing and Configuring the Cloud CPE Centralized Deployment Model

NOTE: Check the Read Me file included with the Cloud CPE Centralized Deployment Model installer for additional information about installing the software.

• Installing Contrail OpenStack on page 39

• Customizing the Configuration File for the Cloud CPE Centralized Deployment Model

Installation on page 39

• Deploying the Cloud CPE Centralized Deployment Model on page 44

Installing Contrail OpenStack

1. install Contrail OpenStack on the server cluster and set up the roles of the nodes in the cluster..

Refer to the Contrail documentation for information about installing Contrail OpenStack and configuring the nodes..

2. Record the IP address of the server on which you install the Contrail OpenStack software.

You use this IP address to specify the Contrail OpenStack server in the configuration file for the Cloud CPE Centralized Deployment Model Installer.

Customizing the Configuration File for the Cloud CPE Centralized Deployment Model Installation

The Cloud CPE Centralized Deployment Model installer uses a configuration file, which you must customize for your network. After you customize the configuration file, you run the installer to deploy and configure the software on the servers and VMs. The

configuration file is located in the server_manager directory and has the name csp_topology.conf. The configuration file is inYAMLformat.

To customize the configuration file:

1. In the [DEPLOY_OPTIONS] section of the file, specify that you have already installed Contrail OpenStack.

skip_contrail_install = True

CAUTION: Do not set the skip_contrail_install option to False. Doing so may corrupt the installation.

(40)

• ip—IP address for the virtual appliance

• user—Username for logging in to the virtual appliance

• password—Password for logging in to the virtual appliance

3. In the [TARGETS] section, specify values for the network on which the Cloud CPE Centralized Deployment Model resides.

• gateway—IP address of the gateway router

• cidr—Range of IP addresses on the network

• admin_email—Administrator’s e-mail address

• domain—Domain associated with administrators’ e-mail address

• dns_servers—Comma-separated list of DNS name servers, including DNS servers specific to your network.

• timezone—Time zone of the host, in the format specified in the Internet Assigned Numbers Authority (IANA) Time Zone Database. The default is the time zone of the installer.

• ntp_servers—Comma-separated list of Network Time Protocol (NTP) servers. For networks within firewalls, specify NTP servers specific to your network.

• servers—Comma-separated list of hostnames of the following components:

• Server on which you install Contrail OpenStack

• The following VMs on the Contrail Service Orchestration node:

• VM that contains Network Service Orchestrator and other components.

• VM that contains Custom Contrail.

• VM that contains Network Service Designer.

• VM that contains the primary instance of Service and Infrastructure Monitor.

• VM that contains the secondary instance of Service and Infrastructure Monitor.

• VM that contains the controller and the load balancer for Service and Infrastructure Monitor.

4. Specify BGP parameters for the MX Series router.

• external_bgp—IP address of the BGP peer

• router_asn—Autonomous system number used for the BGP peer

5. Using the settings configured when you installed Contrail OpenStack, specify the following settings:

• keystone_password—OpenStack keystone password

• keystone_tenant—OpenStack keystone tenant

• keystone_username—OpenStack keystone username

(41)

6. Specify configuration values for the servers and VMs that you specified in Step3.

• [hostname]—Name of the machine

• management_address—IP address of the Ethernet management interface

• management_interface—Name of the Ethernet management interface, typically eth0

• management_mac—MAC address for the host

• data_net_address—IP address of the interface used to transmit data on a physical server

• data_interface—Name of the Ethernet interface used to transmit data on a physical server

• data_mac—MAC address for the interface used to transmit data on a physical server

• gateway—IP address of the gateway for the host. If you do not specify a value, the value defaults to the gateway defined in the [TARGETS] section

• hostname—Hostname of the machine

• username—Username for logging in to the machine

• password—Password for logging in to the machine

• Roles—Components installed on the machine:

• contrail—Server on which you install Contrail OpenStack

• custom_contrail—Contrail software to support Identity and Access Manager component

• iam—Identity and Access Manager

• loadbalancer—Load-balancing software, which balances the volume of traffic for software components that offer redundancy.

• naas—Network as a Service, an application that manages internal event messages

• nsd—Network Service Designer

• nso—Network Service Orchestrator

• sim—Icinga server software

• sim_client—Icinga client software, which resides on the same machine as any component monitored by Service and Infrastructure Monitor.

• sim_primary—Primary instance of Server and Infrastructure Monitor, which works with the secondary instance to provide redundancy.

• sim_secondary—Secondary instance of Server and Infrastructure Monitor, which works with the primary instance to provide redundancy.

• tssm—Cloud CPE, Tenant, Site and Service Manager

(42)

7. (Optional) If you want to reimage the Ubuntu operating system on the Contrail Cloud Platform server with the Ubuntu version included in the installer, specify values for the following Intelligent Platform Management Interface (IPMI) parameters.

CAUTION: Do not specify IPMI parameters for VMs. Doing so may prevent the Cloud CPE Centralized Deployment Model from working.

• ipmi_address—IP address for IPMI.

• ipmi_username—Username for IPMI operations.

• ipmi_password—Password for IPMI operations.

• ipmi_type = ipmilanType of Intelligent Platform Management Interface (IPMI). The Cloud CPE Centralized Deployment Model supports IPMI over LAN (ipmilan) and Integrated Lights-Out (ilo). The default is ipmilan.

8. Specify whether you want to the installer to complete the following tasks:

a. Map the keystone end points to the management network.

b. Install the vSRX image in the Glance software.

c. Optimize settings for Contrail-Openstack, as described in the documentation for that product.

If you have already installed Contrail-OpenStack and it is working correctly, you can chose to omit Step8. If you do so, you must complete Stepaand Stepbmanually. skip_configuration—True or False. The default is false.

The following example shows a customized configuration file for an installation in which you do not want to reinstall Contrail on the Contrail Cloud Platform server:

[DEPLOY_OPTIONS] skip_contrail_install = True [SPACE] ip = 192.0.2.55 user = admin password = pwd1234 [MYSQL] ip = 192.0.2.65 admin_user = admin admin_password = pwd1234 [TARGETS] gateway = 192.0.2.1 cidr = 192.0.2.0/24 domain = location.example.net dns_servers = $next_server, 8.8.8.8 timezone = UTC

(43)

servers = ccp-host, custom-contrail-vm, nsd-vm, nso-vm, sim-vm external_bgp = 192.0.2.60 router_asn = 64512 keystone_password = pwd123 keystone_tenant = admin keystone_username = admin service_token = 229537 [ccp-host] management_address = 192.0.2.10/24 management_interface = eth0 management_mac = 00:25:90:C8:11:86 data_net_address = 192.0.2.12/24 data_interface = eth1 data_mac = 00:25:90:C8:11:88 gateway = 192.0.2.1 hostname = ccp-host username = root password = pwd1234 ipmi_address = 192.0.2.25 ipmi_username = ADMIN ipmi_password = ADMIN ipmitype = ilo skip_configuration = False roles = contrail, sim_client [c-c-vm]

management_address = 192.0.2.3/24 hostname = c-c-vm

username = root password = pwd1234

roles = custom_contrail, sim_client [nsd-vm] management_address = 192.0.2.7/24 hostname = nsd-vm username = root password = pwd1234 roles = nsd, sim-client [nso-vm] management_address = 192.0.2.5/24 hostname = nso-vm username = root password = pwd1234

(44)

password = pwd1234 roles = aim_primary [simcontroller-vm] management_address = 192.0.2.11/24 hostname = simcontroller-vm username = root password = pwd1234 roles = loadbalancer, aim

Deploying the Cloud CPE Centralized Deployment Model

After you have completed all previous installation tasks, you can run the installer from the installer host. To deploy the Cloud CPE Centralized Deployment Model:

1. Log in to the installer VM as root.

2. Access the directory for the installer.

root@host:~/# cd /~/csp1.0/ 3. Run the installer.

root@host:~/csp1.0/# ./install_csp_Solution.sh

The installation begins and you see status messages about the installation.

Setting up CSP Solution Components ============================= This may take a while...

preparing salt prod environment...

4. During installation, view the log file csp_deploy.log to observe detailed messages about the installation of the components.

root@install-host:# cd ~/csp1.0/logs

root@install-host:/csp1.0/logs# tailf csp_deploy.log

In the same directory, you can also view the log file csp_console.log

5. When you see that the deployment is complete, run the verification script.

root@install-host:# cd ~/csp1.0

root@host:~/csp1.0/# ./verify_csp_Solution.sh

If the deployment script installs all components successfully, the verification script returns the following output.

Verifying CSP Solution Components ================================== This may take a while...

---checking health of ---checking health of Custom contrail---checking health of

nfvo---checking health of nsd---checking health of vnfm---checking health of iam---checking health of

icinga---Verification completed for Contrail, JSM, VNFM, NSD, IAM and ICINGA

(45)

• The deployment script was not able to install one or more of the software components.

• One or more software components has not started.

• The software components are not connected correctly.

• The software components are not exchanging tokens correctly. Related

Documentation

•

• Deploying the Cloud CPE Centralized Deployment Model Installer on page 38

Configuring Contrail for the Cloud CPE Centralized Deployment Model

After you have installed the Cloud CPE Centralized Deployment Model, you must configure BGP in Contrail to establish neighborship with the SDN gateway router.

For details, see the following links:

• http://www.juniper.net/techpubs/en_US/contrail2.2/topics/task/installation/admin-control-node.html

• http://www.juniper.net/techpubs/en_US/contrail2.2/topics/task/installation/md5-authentication-configuring.html

Installing and Configuring the Cloud CPE Centralized Deployment Model on page 39

•

Configuring a Junos Space Cluster

The Junos Space cluster provides high availability of the Element Management System. The cluster incorporates two Junos Space Virtual Appliances and two associated databases in a redundant configuration.

To configure the Junos Space cluster:

1. Log into the Junos Space Network Management Web GUI. The dashboard and the Password Expiry dialog box appear.

2. Click Yes in the Password Expiry box to change the default password. The Change User Settings dialog box appears.

3. Enter a new password and click OK,

4. Log out, then log in again with your new password.

5. In the left navigation bar, select Administration > Fabric. The Adminstration > Fabric page appears.

(46)

The Add Node to fabric dialog box appears.

a. Select DB Node for Node Type.

b. Enter the hostname and IP address of the VMs for the primary and secondary Junos Space databases.

c. For the primary database, specify the IP address of the VM for the primary Junos Space Virtual Appliance.

d. Click Add.

7. In the toolbar, click Add Node.

The Add Node to fabric dialog box appears.

a. Select JBoss Node.

b. Enter the hostname and IP address of the VM for the secondary Junos Space Virtual Appliance.

c. Click Add.

•

Creating an LxCIPtable VNF Image

You use this process to make the LxCIPtable VNF available in the Cloud CPE Centralized Deployment Model.

To create an LxCIPtable Image:

1. Fromhttp://cloud-images.ubuntu.com/releases/14.04/release/, download the

appropriate Ubuntu cloud image to the Contrail Openstack server.

2. On the Contrail OpenStack server, upload the Ubuntu image into the Glance software. glance image-create --name IPtables --is-public True --container-format bare --disk-format qcow2 < ubuntu-14.04-server-cloudimg-amd64-disk1.img

3. In a local directory on the Contrail OpenStack server, create a user-data (metadata) file for the image. For example:

bash$ cat user-data.txt #cloud-config

password: <PASSWORD> chpasswd: { expire: False ) ssh_pwauth: True

4. Create an instance of the image called IPtable-temp in this directory.

(47)

CAUTION: Do not delete this instance. Doing so makes the LxCIPtable VNF unavailable in the Cloud CPE Centralized Deployment Model.

5. From the OpenStack GUI, login to the instance with the username ubuntu and the password specified in the user-data file.

6. Customize the instance.

a. Obtain the password specified in the section [ipTables_creds] of the file nfvo.conf.

b. Set the root password to this value. For example: sudo passwd root pwd1234

c. In the file /etc/ssh/sshd_config, specify the following setting:

PermitRootLogin = yes d. Restart the service.

service ssh restart

e. In the file /etc/network/interfaces, modify the eth0, eth1 and eth2 settings as follows:

auto eth0

iface eth0 inet dhcp metric 100

auto eth1

auto eth2

f. Verify that IPtables is active. service ufw status

7. Taking a Snapshot of the Instance.

a. Close the instance. sudo shutdown -h now

b. From the OpenStack Instances page, select Create Snapshot for this instance, and specify the Name as LxcImg 6. You may not delete the temporary instance that we create is Step 3 (named IPtable-temp)

(48)

(49)

Centralized Deployment Model

• Setting Up the NFV Infrastructure for the Cloud CPE Centralized Deployment

Model on page 49

• Adding Customers to the Cloud CPE Centralized Deployment Model on page 52

• Delivering New Network Services to Customers on page 55

• Creating Security Rules for New Customers on page 57

Setting Up the NFV Infrastructure for the Cloud CPE Centralized Deployment Model

After you install the Cloud CPE Centralized Deployment Model, you need to set up the NFV infrastructure, which includes:

• A virtual infrastructure manager (VIM).

• Points of presence (POPs).

• An Internet virtual network.

• A management virtual network. To set up the NFV infrastructure:

1. Log in through the Identity and Access Manager API.

a. Get the authentication information.

curl -X GET -H “Authorization:Basic admin-user xyz” http://<IAMSERVER_IP>:5000/v3/auth/tokens/

b. Assign the result to the OS_TOKEN variable.

2. Create a VIM for the POP.

a. Define information for the VIM in a JSON file. vim.json

{

(50)

b. Create the VIM instance.

curl -X POST -D headers -H "content-type:application/json" "x-auth-token: $OS_TOKEN"

http://<NSOSERVER_IP>:8006/restconf/data/maestro/resource-management/vim-instance -d @vim.json

3. Using the Network Service Orchestrator API, create a POP.

a. Define information for the POP in a JSON file. popid.json { "name": "testpop", "vim-id": "0d604692-87a5-4d9b-a60d-93340b7b7ccd", "compute-zone": "nova" }

b. Create the POP.

http://<NSOSERVER_IP>:8006/restconf/data/maestro/resource-management/nfvi-pop-instance -d @popid.json

c. Define the POP identifier in a JSON file. pop-enable.json { "input": { "pop-id": “<POP_ID>” } }

d. Activate the POP.

http://<NSOSERVER_IP>:8006/restconf/operations/maestro/pop-enable -d @pop-enable.json

e. Get a list of POPs from the Network Service Orchestrator API. curl -X GET "x-auth-token: $OS_TOKEN"

http://<NSOSERVER_IP>:8006/restconf/data/maestro/resource-management/nfvi-pop-instance

f. Assign the result to the POP_LIST variable.

g. Define mapping information for each POP in a JSON file. popid_vcpe.json

{

"pop": {

"type": "jsm", /* cannot be specific to target-type */ "fq_name": [

"jsm-1”, "jsm-popid-1” ],