Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Building Blocks Used for Contrail Service Orchestration Deployments


Contrail Service Orchestration (CSO) uses conceptual and logical elements as building blocks to complete deployments in the GUI. This document provides some discussion about those elements and their use in CSO. For more detailed discussions regarding these elements, see the Contrail Service Orchestration Administration Portal User Guide and Contrail Service Orchestration Customer Portal User Guide.


CSO uses a hierarchical, domain-based administration framework. After CSO installation, the first administrator is named cspadmin by default. This administrator is also known as the global service provider (SP) administrator. This SP administrator has full read and write access to all of the CSO platform from the global domain. In a cloud-hosted CSO deployment, the cspadmin role is reserved for Juniper Networks. The SP administrator can create, edit, and delete other administrators and operators who are subject to role-based access controls (RBAC) that assign them privileges to the rest of the objects in CSO.

In an on-premises CSO deployment, the next level of administrator is the Operating Company or OpCo administrator. In a cloud-hosted CSO deployment, the OpCo admin is the highest level of administrator available to customers. In this case, the first administrator for any given OpCo is created by the SP administrator. This user has full administrative privileges within an OpCo domain. An OpCo can be thought of as a region-specific service provider within the global service provider (such as Juniper Networks). The OpCo administrator can create other administrators and operators within the OpCo domain and its tenants, but can not affect elements of the global domain. Successful login by the OpCo administrator places them into the Administration Portal of their OpCo and they can switch into the Customer Portals of any Tenant of the OpCo.

The other level of administrator is the Tenant administrator. This administrator has full access to all objects within a single tenant and can create other administrator and operator users within that tenant. The tenant administrator’s login places them into the Customer Portal for that Tenant.

There are also operator users at both levels, OpCo, and Tenant. While operator users are not administrators, they can be created by administrators at each level. By default, operators have read-only access to the elements in their domain.


Portals in CSO help to separate the administrators from the customers. CSO has an Administration Portal and a Customer Portal available. Access to any given portal is controlled by a user’s login privileges. If your login does not grant access to the Administration Portal, then you cannot see or access any of the elements of this portal.

Administration portals allow tenant creation and creation of other high-level objects that customers make use of within the customer portals. Administration portals are the highest level of portal within a domain.

Customer portals provide users access to a subset of the objects that exist in administration portals. The primary example of this is that an OpCo administrator can see the Tenants page in the Administration Portal. Each tenant name is a link that, when clicked, takes you to the customer portal for that tenant.

For more information about Administration and Customer Portals, see the Contrail Service Orchestration Administration Portal User Guide and Contrail Service Orchestration Customer Portal User Guide.


CSO uses the tenant element to logically separate one customer from another. An OpCo administrator creates one tenant to represent each customer for which they will provide network services.

Using RBAC and other means such as virtual routing and forwarding (VRF) instances within the network, CSO keeps all tenant and OpCo objects walled within their own space. This ultimately includes the traffic that traverses the customer networks. No individual tenant, its administrators, operators, or customers can see or interact with the objects of another tenant or customer. Tenants can be named in whatever way makes most sense to the SP administrator.


There are four network topologies supported in CSO. When defining a tenant, the OpCo administrator must decide which topology type to assign to the tenant:

  • Service Provider (SP) Cloud Topology—This is generally assumed to be a traditional MPLS topology including provider edge (PE) routers, provider routers (P) and other resources that are owned and managed by the SP.


    In cloud-hosted CSO releases, the OpCo administrator may have no access or read-only access to the SP Cloud and any of its components.

  • Standalone Topology—This topology is one in which the customers, or users of network services remain separate from each other with no means of communication amongst themselves.

    This is the topology of the Hybrid WAN, solution wherein the SP provides network services to its on-premises customers but does not allow them to communicate with one another. Figure 1 shows an example where the virtual network functions (VNFs) are located at an on-premises site, but the site has no access to other sites belonging to the tenant.

    Figure 1: Distributed CPE (or Hybrid WAN)
    Distributed CPE (or Hybrid WAN)

    For more information regarding network function virtualization (NFV) and VNF, see Appendix A - Network Function Virtualization in Contrail Service Orchestration.

    It is also the topology of the NGFW and SD-LAN solutions. The NGFW solution provides for remote site security with SRX Series next-generation firewall devices. The SD-LAN solution provides for remote site LAN management with EX Series LAN access switches and Virtual Chassis. Figure 2 and Figure 3 below show high-level examples of these two solutions.

    Figure 2: Standalone NGFW
    Standalone NGFW
    Figure 3: SD-LAN Solution with EX Switch
     SD-LAN Solution with
EX Switch
  • Hub–and–Spoke Topology—This topology is available for SD–WAN deployments. Given that SD–WAN is intended specifically to enable and enhance the efficacy of WAN communication using network overlays, this topology does allow for communication from site to site. Specifically, if one site needs to communicate with another site, that communication goes through the hub on its way to the other site. Figure 4 shows a very basic example of a hub–and-spoke topology. VNFs can be deployed at any of the locations shown.

    Figure 4: Hub-and-Spoke Topology
    Hub-and-Spoke Topology
  • Dynamic Mesh Topology—This topology is also available for SD-WAN deployments. Direct site–to–site communication is allowed and every site is considered a hub site. Figure 5 shows a very basic example of a full mesh topology. VNFs can be deployed at any of the locations shown. This topology requires more overlay networks than the hub–and–spoke topology so CSO allows for the creation of a full mesh topology as a construct, but the tunnels from one site to another are created dynamically, (or on-demand) based on traffic thresholds thereby conserving resources and improving overall performance.

    Figure 5: Dynamic Mesh Topology
    Dynamic Mesh Topology

    In addition, tunnelling requires the use of mesh tags. Each WAN interface on a CPE device in a dynamic mesh topology is configured with a mesh tag. Tunnels can only be formed between interfaces with matching mesh tags.

Points of Presence (POPs)

A POP is a placeholder, usually at the telco edge or enterprise datacenter, where network services can be deployed and underlay network connections are made to remote sites, as shown in Figure 6. POPs can have PE routers and provider hubs (both data and OAM type).

Figure 6: Points of Presence (POPs)
Points of Presence (POPs)

POPs are used in Hybrid WAN and SD-WAN deployments as a way to locate network access and network services closer to the users who need them. Different network services and different connection types can be offered at each POP, depending on need and availability. POPs can be named in whatever way makes the most sense to the SP administrator.


Sites are the branch offices or remote locations from which customers access the network services provided by the CSO solutions. A site is assigned to a POP and the type of sites available depend on the type of deployment you are creating: SD-WAN, Hybrid WAN, Next Gen Firewall, or SD-LAN. Sites are created by the Tenant administrator. Sites can be named whatever makes sense for the Tenant. Table 1 lists what types of sites can be created within each deployment.

Table 1: Site Types by Deployment


Available Site Types


Service Notes


On-Premises Spoke

Use this site type for placing NFX Series or SRX Series devices at customer sites in either a hub–and–spoke or full mesh topology.

SRX Series devices deployed as on-premises spoke devices can not host VNF–based network services.

NFX devices used as on–premises spoke devices can support ADSL, VDSL, and LTE access links, which can also be used for ZTP. The DSL access links allow configuration of PPPoE. Starting with CSO Release 4.0, LTE access links can be used as primary DATA, OAM, or DATA_OAM links.

Note: ZTP using an xDSL interface will not work if the link is PPPoE. If the link is bridged and uses DHCP, then ZTP will work on xDSL interfaces.

Local breakout is supported on this type of site when using the dynamic mesh topology.

Cloud Spoke

This type of site is specifically for deploying a vSRX in a tenant’s Amazon Web Services (AWS) Virtual Private Cloud (VPC)

Firewall and UTM services are available to protect the customer’s resources in an AWS VPC.

Connectivity between VPC resources and on-premises sites.

WAN_0, WAN_1, and LAN interfaces need to be predefined in the VPC.

Two elastic IP addresses need to be reserved in the VPC to attach to WAN interfaces later.

VPC should be created and attached to an Internet gateway.

Only hub-and-spoke topology is supported.

The hub needs to have public IP addresses on its WAN interfaces.

The hub WAN interface type should be set as Internet during onboarding.

Provider Hub

Use this type of site for placing SRX Series devices in a service provider cloud. The hub devices are used for establishment of IPSec tunnels. Provider hub devices are multi-tenant (shared amongst multiple sites) through the use of VRF instances configured on them.

In a cloud-hosted CSO deployment, an OpCo or Tenant admin can create Provider Hub sites, but not the hub devices themselves. In this case, available hub devices are created by the SP administrator and made available to the lower-level administrators.

You must specify the capability of the hub devices when setting up the site. Specifying OAM capabilities (OAM Hub) allows the hub to help create secure OAM networks with the CPE devices. This option is only available for on-premises CSO deployments.

For cloud-hosted CSO, data hub sites can be added only by an OpCo or tenant administrator.

A hub device is required for the dynamic mesh topology.

Local breakout is not supported on Hub sites.

Enterprise Hub

Use this site type to provide additional hub-like capabilities to those of a normal spoke site.

This type of site has the following capabilities:

  • Can behave as a normal spoke.

  • Anchor point for spokes for dynamic VPN creation.

  • Provides an on-premises central breakout option.

  • Can host a data center department.

  • Can import BGP and OSPF routes from the LAN–side L3 device to create a dynamic LAN segment.

  • Automatically meshed with other gateway sites that belong to the same tenant.

  • Regular spoke sites can be assigned to associate with a gateway site.

  • Supports local, central, and cloud breakout profiles with intent-based rules for more granular breakout control.

Hybrid WAN/Distributed CPE

On-Premises Spoke

Use this site type for locating NFX Series or SRX Series devices at customer sites.

SRX Series devices deployed as on-premises spoke devices can not host VNF–based network services.

NFX devices used as on–premises spoke devices can support ADSL, VDSL, and LTE access links, which can also be used for ZTP. The DSL access links allow configuration of PPPoE. LTE access links can be used as primary DATA, OAM, or DATA_OAM links.

Note: ZTP using an xDSL interface will not work if the link is PPPoE. If the link is bridged and uses DHCP, then ZTP will work on xDSL interfaces.

Local breakout is supported on this type of site when using the dynamic mesh topology.



Use this site type to access EX Series switches in a branch location.

CSO can manage EX Series switches located behind an SD-WAN spoke site or NGFW security device.

Access Point

CSO automatically recognizes any Mist WiFi access points attached to a switch in a branch location.

For SD-WAN and NGFW environments, CSO can detect and manage Mist access points located behind a switch.

Customer Premises Equipment (CPE)

CPE devices are those devices that are placed at remote locations in the site types mentioned previously. CPE devices serve their functions as on-premises spoke devices in Hybrid WAN or SD-WAN deployments. Figure 7 shows available CPE device types.

Figure 7: CPE Devices
CPE Devices

NFX150 and NFX250 Series Network Services Platforms, SRX300, SRX 550M, SRX1500, SRX4100, SRX4200, and vSRX Series Services Gateways can all be deployed as CPE devices. The NFX series devices provide the ability to host VNFs that can be deployed within the Hybrid WAN and SD-WAN solutions. The SRX Series devices cannot host VNFs but can provide their built-in security functions of firewall, UTM, and NAT as protection for the customer sites. In these cases, VNFs can still be deployed behind the SRX, but those VNFs cannot be managed by CSO.

When using SRX1500 or SRX4000 Series Services Gateways, you can create an enterprise hub site that helps implement the on-demand IPsec tunnels used in dynamic mesh topologies.

Standalone Next-Generation Firewall (NGFW)

SRX Series devices can be used as standalone firewalls, managed by CSO in the customer LAN. CSO supports the use of SRX300, SRX320, SRX345, SRX550M, SRX4100, and SRX4200 line of devices as well as the vSRX for this purpose. In this next-generation firewall (NGFW) scenario, the SRX acts as a CPE device but provides no site–to–site or site–to–hub communications as with an SD-WAN solution.

You can add LAN capabilities along with or after the deployment of an NGFW site.

SD-LAN Devices

EX Series LAN access switches can be used as CPE devices to provide managed LAN services at branch sites. This SD-LAN solution supports the use of the EX2300, EX3400, EX4300, EX4600, and EX4650 line of switches in either a standalone or Virtual Chassis configuration. These switches provide CSO-managed LAN capabilities, and you can deploy them behind an unmanaged WAN router, a CSO–managed CPE device, or NGFW device. In addition, you can add Mist WiFi access points behind the switches to provide both wired and wireless services.

In addition, CSO supports dynamic routing protocols such as BGP and OSPF in the local LAN. Therefore, when SD-LAN is configured using any of the above devices, routes to the site LANs can be updated dynamically with BGP or OSPF. For more information, see Hybrid WAN Deployment Architecture.

Virtual Route Reflector (VRR)

The VRR is part of CSO's SD–WAN controller. It is one of the virtual machines that get provisioned and installed during the installation process. To facilitate the routing needed in the SD–WAN deployment , the VRR forms BGP sessions with CPE spokes and hub devices using the underlay interface designated as OAM or OAM_AND_DATA during the configure site GUI workflow for site onboarding. The OAM interfaces can be implemented using dedicated IPSec tunnels which allows CPE and hub devices to be behind NAT. Figure 8 illustrates the concept of the VRR

Figure 8: VRR Overview
VRR Overview

SLA-Based Steering Profiles and Policies

CSO allows for the creation of SLA–Based steering profiles that can be mapped to SD–WAN policy intents for traffic management in an SD–WAN deployment. The profiles are designed to steer traffic to a specific WAN link based on SLA parameters such as packet loss, round trip time (rtt), and jitter thresholds. SLA steering profiles are created for global application traffic types for all tenants. An SLA profile consists of a set of configurable constraints that can be defined in the Administration Portal.

You can set:

  • Path preference for each of the connection paths from site–to–site

  • Path preference for each of the connection paths from site–to–hub

  • Threshold parameters for throughput

  • Threshold parameters for packet loss

  • Threshold parameters for latency

  • Threshold parameters for jitter

  • Class of service for various types of traffic

  • Rate limiters to control upstream and downstream traffic rates and burst sizes

Once the steering profile exists, an intent-based SD–WAN policy can be created that applies that profile to specific sites or departments and against specific types of application traffic such as SSH and HTTP.


When creating an SLA profile, you must set either path preference or one of the SLA parameters. Both fields cannot be left blank at the same time.

See SLA Profiles and SD-WAN Policies Overview for more details.

Path Based Steering Profiles

Path based steering profiles are a simplified way to steer global application traffic types onto a specific WAN path. With these profiles, you do not need to configure any SLA parameters. All you need to do is specify which available path you want a specific traffic type to take. Just as with SLA steering profiles, you can set rate limiting parameters for these profiles. You must also assign these profiles to an SLA policy before they take effect.

Intent-based Firewall Policies

Accessed through the Customer Portal, CSO presents firewall policies as intent-based policies. Firewall policies provide security functionality by enforcing intents on traffic that passes through a device. Traffic is permitted or denied based on the action defined as the firewall policy intent. If your intention is to block HTTP-based traffic from social media sites, but allow HTTP-based traffic from Microsoft Outlook, you can create an intent policy to do that.

See Firewall Policy Overview for more information.

Software Image Management

The CSO Administration Portal allows SP administrators (cspadmin) to upload device software images and VNF images on the Resources > Images page. The cspadmin user in an on-premises CSO deployment can upload device images for supported SRX Series devices (including vSRX), NFX Series devices, and EX Series devices. He or she can also upload VNF images created in the Designer Tools applications.

For cloud-hosted versions of CSO, an OpCo administrator can see the images that have been uploaded to CSO by Juniper Networks. He or she can also stage and deploy uploaded device images to CPE devices and EX Series access switches.