Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

SD-WAN Deployment Architectures

 

An SD-WAN implementation offers a flexible and automated way to route traffic from site to site. As shown in Figure 1, a basic SD-WAN architecture includes just a few basic elements

  • Multiple sites

  • Multiple connections between sites that form the underlay network

  • A controller

  • Multiple overlay tunnels

Figure 1: SD-WAN Architecture
SD-WAN Architecture

The SD-WAN controller, built-in to CSO, acts as an orchestration layer and provides an interface, allowing the operator to setup and manage the devices at the sites.

SD-WAN Reference Architecture

Juniper’s Contrail SD-WAN solution architecture, shown in Figure 2 using a hub-and-spoke topology, is based on the distributed cloud CPE model, with CPE devices located at customer branch sites. On the local side of the site, the CPE devices connect to LAN segments; on the WAN side, the CPE devices connect across two or more links to a hub device. With the SD-WAN model (in a hub-and-spoke topology), traffic travels from site to site through the hub. By default, traffic going to the Internet also flows through the hub device.

Figure 2: SD-WAN Reference Architecture
SD-WAN Reference
Architecture

The SD-WAN orchestrator and controller functions are implemented through Juniper’s Contrail Service Orchestration (CSO) software. The CSO platform uses policies and SLA parameters to differentiate and direct traffic flows across the available paths as desired.

The following sections describe these architectural elements in more detail.

Spoke Devices

The CPE device at an Enterprise customer’s branch site acts as a spoke device in the SD-WAN model. The device also acts as a “gateway router” (GWR), providing connectivity from the branch site to other sites in the tenant network and to the Internet. There are two types of spoke devices: on-premise spoke and cloud spoke.

On-premise Spoke Devices

Figure 3: On-premise Spoke Devices
On-premise Spoke Devices

On-premise spoke devices can be either NFX Network Services devices or specific SRX Series Services Gateways. Table 1 shows the supported NFX hardware and required Junos OS software release version for each supported model.

NFX Network Services Platform

The NFX Network Services platform differentiates from traditional CPE devices in that it can host a range of multivendor VNFs and support service chaining, managed by orchestration software in the Cloud. NFX devices eliminate the operational complexities of deploying multiple physical network devices at a customer site.

A key VNF supported on the NFX platform is the vSRX Virtual Firewall. In the Contrail SD-WAN solution, the vSRX instance performs the GWR function, given its routing and switching capabilities. It also provides the same feature-rich security services found on a standard SRX Series Services Gateway.

Note

The NFX150 includes SRX functionality natively built in.

Table 1: NFX Hardware and Software Matrix for On-premise Spoke Devices

Platform

Models Supported

Junos OS Software Release Version

NFX150 Network Services Platform

  • NFX150-S1

  • NFX150-S1E

  • NFX150-C-S1

  • NFX150-C-S1-AE/AA

  • NFX150-C-S1E-AE/AA

18.2X85-D11

NFX250 Network Services Platform

  • NFX250-LS1

  • NFX250-S1

  • NFX250-S2

15.1X53-D496.0

SRX Series Services Gateways and vSRX Virtual Firewall

A physical SRX device can be used in place of the NFX platform to provide the GWR function, as can a vSRX instance installed on a server. Table 2 shows the supported SRX hardware and required Junos OS software release version.

Table 2: SRX Hardware and Software Matrix for On-premise Spoke Devices

Platform

Models Supported

Junos OS Software Release Version

SRX Series Services Gateway

  • SRX4100 Services Gateway

  • SRX4200 Services Gateway

  • SRX300 Services Gateway

  • SRX320 Services Gateway

  • SRX340 Services Gateway

  • SRX345 Services Gateway

  • SRX550M Services Gateway

151_X49_D161

vSRX Series Virtual Services Gateway

vSRX

151_X49_D170

Gateway Sites and DevicesStarting with CSO Release 4.1, a special type of spoke device, called a Gateway Device, can be deployed as the CPE at an on-premise spoke. Only SRX4100 and SRX4200 Services Gateway devices can serve this function. The spoke site that functions this way, must be configured as a gateway site during site creation. Creating a gateway site with an SRX4x00 opens additional functionality for the site:

  • Can act as the anchor point for site-to-site communications on the customer’s network

  • Can act as the central breakout node for the customer’s network

  • Provides for a new, specialized, department called the data-center department

  • Supports dynamic LAN segments with BGP and OSPF route imports, including default routes, from the LAN-side L3 device.

  • Allows for intent-based breakout profiles to create granular breakout behavior based on department, application, site, etc.

Cloud Spoke Devices

Starting in CSO Release 3.3, an SD-WAN spoke device can be located in an AWS VPC. A vSRX instance in the VPC serves as the cloud spoke device; once the endpoint comes online it acts like any other spoke device.

Spoke Redundancy

Starting with CSO Release 3.3, dual CPE devices can be used at spoke sites to protect against device and link failures. For more detail, see the Resiliency and High Availability section of the Contrail SD-WAN Design and Architecture Guide.  

Hub Devices (SD-WAN Gateway)

The SD-WAN solution supports two deployment topologies (discussed later in this guide): dynamic mesh and hub-and-spoke. In a dynamic mesh deployment, each site has a CPE device that connects to the other sites and the gateway device. In a hub-and-spoke deployment, there is at least one hub device and one or more spoke devices.

A hub device acts as the SD-WAN gateway, terminating MPLS/GRE and IPsec tunnels from spoke devices. The hub is sometimes referred to as an SD-VPN gateway, given its role as an IPsec concentrator.

Note

Starting with CSO Release 4.0, the on-premise hub is no longer supported.

Cloud Hub

In a service provider environment, a cloud hub is owned by the service provider and the hub device resides within the service provider’s network (POP). It is typically a “shared” device, providing hub functionality to multiple customers (tenants).

In an enterprise environment, the cloud hub is owned by the customer (tenant) and the hub device resides within the enterprise data center. Only the customer’s spoke sites can connect to its hub device.

Figure 4: SD-WAN Hub Devices
SD-WAN Hub Devices

As of CSO Release 4.1, the supported hub devices are shown in Table 3

Table 3: Hub Devices

Role

Supported Device Types

Required Junos OS Software Version

Usage Notes

Cloud Hub

  • MX Series Devices with Services Line Cards

  • SRX1500 Services Gateway

  • SRX4100 Services Gateway

  • SRX4200 Services Gateway

  • vSRX

For MX Series Devices: 16.1R5.7

For SRX Series Devices: 15.1X49-D161

For vSRX: 15.1X49-D170

The requirement for the Services Line Card (MIC or MPC) is there so that the MX can terminate IPsec tunnels.

See MPCs Supported by MX Series Routers and MICs Supported by MX Series Routers for information about MX Series routers that support Multiservices MPC and MIC line cards

Hub Redundancy

Starting with CSO Release 3.3, dual hub devices can be used to protect against device and link failures, and to provide upstream multihoming for spoke sites. For more detail, see the Resiliency and High Availability section of the Contrail SD-WAN Design and Architecture Guide  .

Underlay (Physical) Network

The underlay network includes the physical connectivity between devices in the SD-WAN environment. This layer of the network has no awareness of the customer LAN segments, it simply provides reachability between on-premise devices.

Figure 5 shows a sample underlay network for a hub-and-spoke SD-WAN deployment (the details apply equally to a full mesh setup). Each spoke site typically has multiple paths to the hub site: in this case, one through the private MPLS cloud, and one over the Internet.

Figure 5: SD-WAN Underlay Network
SD-WAN Underlay Network

Each on-premise device can have up to four WAN links. During configuration, CSO identifies the devices’ WAN-facing interfaces as WAN_0 through WAN_3.

Note that

  • The WAN interfaces can be VLAN tagged or untagged, as per design requirements.

  • All on-premise devices’ MPLS network-facing interfaces must be attached to a single Layer 3 VPN provider.

  • The on-premise devices’ Internet-facing interfaces can be attached to different service provider networks.

WAN Access Options

The following WAN access types are supported

  • MPLS

  • Ethernet

  • LTE (LTE WAN access supported on NFX250 devices starting with CSO Release 3.3. LTE WAN access supported on NFX150 devices starting with CSO Release 4.0.0.)

  • ADSL/VDSL (ADSL/VDSL WAN access supported on NFX devices starting with CSO Release 4.0.0

WAN Interface Types - Data and OAM

The WAN interfaces are used primarily to forward and receive user traffic (data). At least one of the WAN interfaces must also be used for management (OAM) traffic. The OAM interface is used to communicate with CSO, and allows CSO to manage the on-premise device.

Figure 6 illustrates these two interface types.

Figure 6: WAN Interface Types
WAN Interface Types

Note that

  • The on-premise device’s OAM interface must be able to reach CSO.

  • To ensure secure communication over the WAN, the on-premise device initiates the connection to CSO.

  • Device-initiated connections can work across intermediate NAT devices.

  • The user-and-OAM-data interface can use a single IP address for both functions.

Overlay (Tunnels) Network

The overlay network includes the logical tunnel connectivity between devices in the SD-WAN environment. This layer of the network has awareness of the customer LAN segments, and is responsible for transporting customer traffic between sites.

Figure 7 shows an overlay network for a hub-and-spoke environment. Each spoke site has two tunnels to carry traffic to the hub site: one through the private MPLS cloud, and one over the Internet.

Figure 7: SD-WAN Hub-and-Spoke Overlay
SD-WAN Hub-and-Spoke
Overlay

The tunnels have two encapsulation options: MPLSoGRE or MPLSoGREoIPsec. CSO automatically provisions and establishes these tunnels as part of the deployment process.

Overlay Deployment Topologies

The SD-WAN solution supports hub-and-spoke or dynamic mesh deployment topologies.

With the hub-and-spoke topology, all spoke sites are connected to at least one hub site, as shown in Figure 8. Spoke sites cannot communicate directly with other spoke sites.

Figure 8: SD-WAN Hub-and-Spoke Topology
SD-WAN Hub-and-Spoke
Topology

This topology is preferred when applications and services are centralized at the hub site.

With the dynamic mesh topology, all sites are interconnected, as shown in Figure 9, and each site can communicate directly with every other site. Although the figure shows the DATA_AND_OAM connection on the MPLS link, WAN_0, this function can be performed on either the MPLS or Internet links.

Figure 9: SD-WAN Full Mesh Topology
SD-WAN Full Mesh Topology

This topology is well suited for deployments where applications and services are not centralized.

Note

Starting with CSO Release 4.0, both hub-and-spoke and full mesh topologies require adding a secure OAM network overlay, and thus an OAM Hub, to the deployment.

SD-WAN Orchestrator/Controller

The SD-WAN orchestration and controller functions are implemented through Juniper’s Contrail Service Orchestration (CSO) software. CSO software offers a Web-based UI to manage the SD-WAN environment, as shown in Figure 10.

Figure 10: CSO Dashboard
CSO Dashboard

CSO is built with multiple layers of abstraction for usability and scalability, as shown in Figure 11. The platform implements these layers using orchestration software and controller software.

Figure 11: CSO Abstraction Layers
CSO Abstraction Layers

The Service Orchestration Layer contains the Network Service Orchestrator (NSO). The orchestration software has a global view of all resources and enables tenant management, providing end-to-end traffic orchestration, visibility, and monitoring. The Domain Orchestration Layer contains the Network Service Controller (NSC). The orchestration software works together with the controller to manage on-premise (CPE) devices, and provide topology and CPE lifecycle management functionality.

At the user level, CSO provides the interface to deploy, manage, and monitor the devices in the SD-WAN network through the NSC. At the network level, NSC includes a vRR that allows each site to advertise its local routes to remote sites.

For more information regarding SD-WAN architecture, see Contrail SD-WAN Design and Architecture Guide  .

Release History Table
Release
Description
Starting with CSO Release 4.1, a special type of spoke device, called a Gateway Device, can be deployed as the CPE at an on-premise spoke. Only SRX4100 and SRX4200 Services Gateway devices can serve this function.
As of CSO Release 4.1, the supported hub devices are shown in Table 3
Starting with CSO Release 4.0, the on-premise hub is no longer supported.
LTE WAN access supported on NFX150 devices starting with CSO Release 4.0.0
ADSL/VDSL WAN access supported on NFX devices starting with CSO Release 4.0.0
Starting with CSO Release 4.0, both hub-and-spoke and full mesh topologies require adding a secure OAM network overlay, and thus an OAM Hub, to the deployment.
Starting in CSO Release 3.3, an SD-WAN spoke device can be located in an AWS VPC. A vSRX instance in the VPC serves as the cloud spoke device; once the endpoint comes online it acts like any other spoke device.
Starting with CSO Release 3.3, dual CPE devices can be used at spoke sites to protect against device and link failures.
Starting with CSO Release 3.3, dual hub devices can be used to protect against device and link failures, and to provide upstream multihoming for spoke sites.
LTE WAN access supported on NFX250 devices starting with CSO Release 3.3