ATCPalo AltoProof of Concept (POC)ATC InsightSoftware Defined WAN (SD-WAN)Networking
ATC Insight •
Moderate
• • 28 minute read

Testing Palo Alto Prisma SD-WAN in the ATC

Palo Alto has long been known as a global cyber-security leader. Since their acquisition of CloudGenix in 2020, Palo has been helping to shape the cloud-centric model by adding SD-WAN (Software-Defined Wide Area Network) into a holistic SASE offering including Prisma Access for customers and an ever-evolving industry. The ATC (Advanced Technology Center) worked to build a lab within a few weeks that would test, showcase, and demonstrate Palo Alto's SD-WAN cloud-native network approach. Keep reading to see how Palo Alto completes their SASE solution.

In this ATC Insight

 

 ATC Insight

Palo's SDWAN Technology

Palo Alto takes a next-generation application-defined holistic approach at looking at application traffic that goes above layer 3 and into layer 7 for troubleshooting application performance issues. Prisma IONs perform stateful inspection and application-based (layer 7) firewalling with east-west segmentation and inspection. 

The solution is flow and session-based which allows Prisma to utilize a novel approach to steering wan traffic by looking at the transactional success and failure statistics. Factors that are built into the structure which influence the traffic path selection and engineering include TCP initiation, server response times, MOS scores for real-time traffic, and other layer 7 elements. This allows the device to perform automated asymmetric flow correction on the underlay and overlay. 

Path-correction also comes in the form of measured metrics such as loss, latency, and jitter as well as application performance within the session flows. If an application starts seeing retransmissions for example, the path can be auto corrected for that application alone even on the underlay. Meaning that even tunnels that are not bookended to SSE's (Security Services Edge providers) such as Prisma Access can be measured for performance and path corrected based upon the number of transaction failures the current path has versus the number of transaction successes.

Prisma SDWAN also utilizes auto correction for asymmetrical routing and requires no extensive or complex filtration on routing. This is due to the unique approach of using core and edge BGP routing and auto route-maps to influence the traffic to the correct path.

Traffic steering can be performed with their app-id and policy control brought over from CloudGenix. The newest code release brings in the extensive app-ids from Panorama which will help unify the products.

CloudGenix Dynamic Path Selection.pdf

Components

Components that make up a Prisma SDWAN environment are few and include a cloud-based controller with an intuitive graphical user interface and edge devices which make up the branches and data centers.

Sites are utilized within the controller portal and include the branch and DC edges.

Cloud Blades are extensions which allow customers to integrate third-party services with just a few clicks within the cloud portal.

Intuitive Graphical User Interface

Palo Alto's Prisma SDWAN portal is very intuitive when it comes to onboarding new sites or devices, troubleshooting issues, or configuring policies. All aspects of the SDWAN solution are managed within the controller portal. Very little in the way of configuration is available locally aside from basic interface settings for control connectivity. There is even an embedded CLI that is available to access the edge devices from within the portal. It is a one-stop shop for deploying Prisma SD-WAN, claiming devices and assigning them to sites, and configuring the ION devices for your sites.

This lab utilized both physical and virtual ION devices. Regardless of the physical nature of the device, the onboarding process was very easy and includes an activation email that links back to the controller portal where the device is brought into an unclaimed state. From there it can be claimed, added to a site, and configured for deployment.

Extensive Support and Documentation

Palo Alto supplies an extensive up-to-date library for documentation repository and guides on their site. Anything from initial turn-up to adding Cloud Blade services to your solution can be found in their repositories and laid out in a way that can walk anyone through their processes. All of these documents can be downloaded as a pdf for offline reference from their TechDocs site. There is also a knowledge base in the customer support portal.

https://docs.paloaltonetworks.com/prisma/prisma-sd-wan

Seamless Third-Party Integrations With Prisma CloudBlades

The concept of Prisma CloudBlades allow for seamless third-party integrations for more 20 services. These templates developed through Prisma with the respective Partners can be deployed with day-1 integration so that customers and branches can utilize the services immediately. Some offerings include Prisma Access, AWS, GCP, Zoom, Splunk, and ServiceNow.

The CloudBlade Platform provides secure, authenticated API access. This API layer provides for centralized API programming with integration into the Prisma SDWAN UI with 3rd party technologies without code. This allows for build-out of cloud services without dependencies on firmware, sdwan appliance, or controller. Other vendors can run their own cloud blade for integration. For example, Service-Now cloud blade can kick off tickets based on machine-learning to tie into the remediation pipeline.

High-speed multi-cloud backbones are also enabled for CloudBlade connectivity to the branches.

Prisma Access Cloudblade Integration Guide.pdf

 Layer 1 and 2 Low-Level Design

Layer 1 / 2 - 2 data centers, 2 SD-WAN sites, and 1 legacy site

 Layer 3 Low-Level Design Underlay and Overlay

 Layer 3 - 2 data centers, 2 SD-WAN sites, and 1 legacy site

 Underlying Lab Components 

  1. (1) Cisco UCSC-C240-M5SX - ESXi version 6.7
    1. Houses virtual environment
      1. (2) Traffic-Jam used for INET and MPLS SIM ISPs and traffic impairments - FRRouting 3.0.2
      2. (4) virtual Prisma VION-7108 (2) per data center - version 5.6.3-b12
      3. (2) Windows jumpboxes - Windows 10/Windows 2016 Server
      4. Panorama - version 10.1.5
  2. (2) Cisco Catalyst WS-3560G-24PS Switch 24 port - version 12.2(58)SE2
    1. SIM Switch used to simulate ISP traffic
    2. Branch LAN switch for all branch segmentation
  3. (2) Catalyst WS-3560X-24T-S Switch 24 port - versions 15.2(4)E10/15.2(4)E6
    1. One per data center for lan segmentation
  4. (2) Palo Alto Networks PA-850 - version 10.1.5
    1. One per data center used for INET access for backhauled traffic
  5. (2) Cisco ISR 2951 - version 15.2(4)M3
    1. One per data center for WAN CPE
  6. (1) Cisco ISR 2911 - version 15.1(4)M1
    1. Used for non-SDWAN branch

 Technologies and Devices Under Test

  1. (4) ION 7K VM - version 5.6.3-b12
    1. Virtual Prisma ION-7108v (2) per data center
  2. (3) ION 2000 FW-7525D-CGI Network Appliance - version 5.6.3-b12
    1. (2) Branch 1 HA pair
    2. (1) Branch 2

 Testing Tools

  1. (1) Ixia Traffic Generator - Model: XGS12 - OS: 9.00.1900.10
  2. (5) Ixia 1Gb Interfaces - Model: IxLoad XCellon-Ultra NP - OS: 9.00.115.99

Simulated traffic and flows for http, ftp, and voice are configured on the Ixia Traffic Generator with emulated agents and servers configured to send various traffic types at specified bandwidths according to the test at hand. Each agent is configured according to the service vlan on the branch lan segments with the hosts pointing to the edge gateways respectively. The DC servers are configured similarly with the gateways configured on the core switches.

Data Center

Port 1 - 10 hosts per vlan 

  1. VLANS 220,230,240
    1. Vlan220 Data
      1. GW:10.1.4.129/26
      2. Hosts 10.1.4.130 – 10.1.4.139
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    2. Vlan230 Voice
      1. GW:10.1.4.193/26
      2. Hosts 10.1.4.194 – 10.1.4.203
      3. Traffic flows for SIP/RTP, Various throughput ranges
    3. Vlan240 Guest
      1. GW:192.168.4.1/24
      2. Hosts 192.168.4.2 – 192.168.4.11
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges

Port 2 - 10 hosts per vlan

  1. VLANS 320,330,340
    1. Vlan320 Data
      1. GW:10.1.5.129/26
      2. Hosts 10.1.5.130 – 10.1.5.139
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    2. Vlan330 Voice
      1. GW:10.1.5.193/26
      2. Hosts 10.1.5.194 – 10.1.5.203
      3. Traffic flows for SIP/RTP, Various throughput ranges
    3. Vlan340 Guest
      1. GW:192.168.5.1/24
      2. Hosts 192.168.5.2 – 192.168.5.11
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges

Branches

Ports 3,4,5 - 10 hosts per vlan

  1. VLANS 20-100
    1. Vlan20 Br1-Data
      1. GW:10.1.1.1/26
      2. Hosts 10.1.1.4-10.1.1.13
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    2. Vlan30 Br1-Voice
      1. GW:10.1.1.65/26
      2. Hosts 10.1.1.68-10.1.1.77
      3. Traffic flows for SIP/RTP, Various throughput ranges
    3. Vlan40 Br1-Guest
      1. GW:192.168.1.1/24
      2. Hosts 192.168.1.4-192.168.1.13
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    4. Vlan50 Br2-Data
      1. GW:10.1.2.1/26
      2. Hosts 10.1.2.2-10.1.2.11
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    5. Vlan60 Br2-Voice
      1. GW:10.1.2.65/26
      2. Hosts 10.1.2.66-10.1.2.75
      3. Traffic flows for SIP/RTP, Various throughput ranges
    6. Vlan70 Br2-Guest
      1. GW:192.168.2.1/24
      2. Hosts 192.168.2.2-192.168.2.11
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    7. Vlan80 Br3-Data
      1. GW:10.1.3.1/26
      2. Hosts 10.1.3.2-10.1.3.11
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges
    8. Vlan90 Br3-Voice
      1. GW:10.1.3.65/26
      2. Hosts 10.1.3.66-10.1.3.75
      3. Traffic flows for SIP/RTP, Various throughput ranges
    9. Vlan100 Br3-Guest
      1. GW:192.168.3.1/24
      2. Hosts 192.168.3.2-192.168.3.11
      3. Traffic flows for HTTP, HTTPS, FTP, Various throughput ranges

 Test Bed Interconnectivity

Branch one uses two ION 2000 FW-7525D-CGI SDWAN Network Appliances connected in active/standby HA with the controller port as their peering interface. The branch utilizes one INET and one MPLS 1Gb wan connection to the ISP clouds. Each ION is also connected to the other via bypass pairs. This allows each to utilize the others wan connectivity in the event of failover. There is a default route to the INET ISP and a BGP peer with the MPLS ISP. The MPLS ISP BGP peer advertises the data center prefixes as well as a default route. In exchange, the branch lan prefixes are statically defined on the INET ISP and advertised via MPLS BGP. The branch lan is connected via Cisco Catalyst WS-3560G-24PS 24-port switch that segments each branch at layer 2. Each ION shares a virtual IP for each VRRP instance that is the gateway for each service vlan (data, voice, guest).

Branch two is a stand-alone site that uses one ION 2000 FW-7525D-CGI SDWAN Network Appliance with two INET 1Gb wan connections to the INET ISP. There is a default route to the INET ISP and the branch lan prefixes are statically defined on the INET ISP. The branch lan is connected via Cisco Catalyst WS-3560G-24PS 24-port switch that segments each service and branch at layer two. The ION is configured with the gateway for each service vlan (data, voice, guest). The INET Traffic-Jam has a route to each service subnet via the wan interconnects.

Branch three is a non-sdwan site that represents a legacy site which incorporates a Cisco ISR 2911 router at the wan edge with a single 1Gb BGP peering to the MPLS ISP. The lan branch lan prefixes are advertised to BGP and a default route is received. This branch lan is also connected to the Cisco Catalyst WS-3560G-24PS 24-port switch that segments each service and branch at layer two. 

Data Centers one and two are configured with two virtual Prisma ION-7108v SDWAN Network Appliances each. Both DC edges acts as active and both forward traffic simultaneously. Each edge has a BGP peer with the MPLS CPE. As well, each MPLS CPE has a BGP connection back to the data center core switch. There is static routing in place for the INET connections. Both devices also perform auto route segmentation on the LAN side to split prefixes. When the DC edge devices see the branch lan prefixes advertised from the wan, they will split them in half before advertising them to the DC lan core BGP peers. For example, if they see a /26 branch prefix learned via the MPLS BGP peers and via the overlay, it splits the traffic into two /27 prefixes and advertises one toward each core BGP peer. This not only prevents loops but ensures that the longest prefix will be preferred at the DC.

Data center peers can be defined as Core or Edge peers. Each peer has an automated route-map applied to prevent route loops and help with asymmetrical routing. For Core peering, prefixes are advertised to the core, but the edge will not receive any prefixes from the core. An Edge peer will receive prefixes but not send any.

Each DC core switch (one per DC) provides the gateways and layer two connectivity to the servers. A DCI (DC Interconnect) is configured between each core switch for backup routing in the event of a DC failure. Each switch also has a connection to a Palo Alto Networks PA-850 firewall used for INET access for backhauled traffic.

The DC core switches are also peered up with the MPLS-CPE routers.  This allows for easy installation of the SDWAN devices with no impact to existing traffic flows or routing.

 Test Plan/Test Cases

 1. Management

1.1 Cloud Managed

The purpose of this test is to demonstrate cloud management and orchestration capabilities.  The vendor is expected to provide a solution that does not use any on-premise virtual machines or hardware for device management.

Recorded Results

PASS: Prisma SD-WAN utilizes a cloud-based controller where all aspects of the SD-WAN solution is managed from onboarding to traffic steering and policy enforcement. This can be centrally found under  https://apps.paloaltonetworks.com.

1.2 Role Based Access Control

The purpose of this test is to determine if the SD-WAN solution supports RBAC and/or multi-tenancy.  User account access should be successfully restricted and views hidden depending on roles.

Recorded Results

PASS: Prisma SD-WAN is able to perform RBAC on accounts managed by an administrator locally in the Prisma portal or under the Customer Support Portal. As well, the solution allows for external integration of user management controls and Prisma Access integration for authentication support. https://docs.paloaltonetworks.com/prisma/prisma-access/prisma-access-cloud-managed-admin/identity-services/authentication/authentication-support

 2. Automation

2.1 RESTful API

PASS: Prisma has an SDK in python within https://github.com/CloudGenix that is the most common way to interact with the API. An Auth Token must be created in the portal for authentication to the API. The token then gets added to the cloudgenix_settings.py file.

There is also a cloudgenix_config script to help with exporting device configurations via YAML files using pull_site. Those same files can be edited and reuploaded to the device using the do_site command. Also, variables can be configured for multi-site configuration and pushed to Jenga. For this test, we pulled the branch 2 device configuration, edited the YAML file to admin down interface 1.70, and pushed the config back to the device. The CloudGenix Developers portal contains help and guides for integrating into existing workflows.

https://developers.cloudgenix.com/login

2.2 Built-In Capabilities

The purpose of this test is to demonstrate how changes can be pushed down to multiple devices without requiring the network administrator to manually input the change at each device in the SD-WAN.

Recorded Results

PASS: Palo's Prisma SDWAN performs automation via their CloudBlade integration. This is a completely free built-in solution that allows seamless cloud service integrations. These can be accessed by submitting a request into the customer support portal for the CloudBlade service to be added to your tenant. Once configured, the controller auto configures the necessary tunnels for the service for each site that is enabled.

2.3 Zero Touch Provisioning

The purpose of this test is to identify key facts regarding the ZTP process and demonstrate it at one of the sites in the lab.

Recorded Results

PASS: This lab utilized both physical and virtual ION devices. Regardless of the physical nature of the device, the initial onboarding process included connecting the controller port to the Internet so that it can form a connection with the controller. Each device is tied to the respective tenant via serial number. Once connection is established, the device is brought into an unclaimed state. From there it can be claimed, assigned to a site, and configured for deployment.

 3. Routing

3.1 BGP IPv4 Support

The purpose of this test is to demonstrate support for BGP and the IPv4 address family. Depending on customer requirements, eBGP, iBGP, or both may need to be deployed.  Features such as route filters, AS path prepend, and standard communities may need to be configured to show functionality with existing or planned routing strategies.

Recorded Results

PASS: BGP routing is setup on the underlay and overlay for path control and connectivity between the sites and data centers. Typically, manipulation of branch route-maps is limited to the complexity of the site being deployed but are not always needed. Branch peers are defined as local or global. Global peers will advertise their prefixes into the sdwan fabric, local does not. Only the active device in a branch HA configuration will form BGP relationships and pass traffic. In steady state, the active device can form an MPLS BGP peering relationship through the bypass-pair using the secondary devices MPLS circuit.

Each DC edge acts as active and both forward traffic simultaneously. Each edge has a BGP peer with the MPLS cpe. As well, each MPLS cpe has a BGP connection back to the data center core switch. When the DC edge devices see the branch lan prefixes advertised, they split them in half before advertising them to the DC lan. For example, if they see a /26 branch prefix learned via the MPLS BGP peers and via the overlay, it splits the traffic into two /27 prefixes and advertises one toward each core BGP peer. This not only prevents loops but ensures that the longest prefix will be preferred at the DC.

Data center peers can be defined as Core or Edge peers. Each peer has an automated route-map applied to prevent route loops and help with asymmetrical routing. For Core peering, prefixes are advertised to the core, but the edge will not receive any prefixes from the core. An Edge peer will receive prefixes but not send any. 

3.2 Flow Based Routing Support 

The purpose of this test is to demonstrate support for Flow based routing.  Features such as NTT, RTT, SRT, Initiation Failures, as well as Transmission Failures are needed to to show functionality with existing or planned routing strategies in the event of a brown out.

Recorded Results

PASS: Palo Alto Prisma SDWAN IONs are session-based devices and not packet forwarding devices. This allows the device to perform automated asymmetric flow correction.

One use case would be if a third-party resource fails from DC1 to DC2, the route to the resource and the policy did not change. The traffic hits the DC1 Core, crosses the DCI (Data Center Interconnect) to traverse DC2 to reach the resource. The return traffic then takes the normal southbound path via DC2 to the branch. Once the branch edge sees the return traffic coming from DC2, it will auto path-correct to send traffic directly to DC2 to maintain the symmetry.

Path-correction also comes in the form of measured metrics such as loss, latency, and jitter as well as application performance within the session flows. If an application starts seeing retransmissions for example, the path can be auto corrected for that application alone even on the underlay. Meaning that even tunnels that are not bookended to SSE's (Security Services Edge providers) such as Prisma Access can be measured for performance and path corrected based upon the number of transaction failures the current path has versus the number of transaction successes.

For this test, we introduced 10 percent bidirectional loss on the DC1 INET wan transport. The Prisma SDWAN device auto corrected the app flow based on the metrics and steered the traffic to the DC2 INET connection accordingly. Once the impairment was removed, traffic was auto corrected back to the original path.

3.3 GRE/IPsec Tunneling

The purpose of this test is to demonstrate support for tunneling mechanisms to non-SD-WAN devices.  Depending on customer requirements, this could be a GRE (point-to-point, unencrypted) or IPsec IPv4 (point-to-point, encrypted).

Recorded Results

PASS: The Prisma SDWAN can successfully be configured for manual or automatic IPSEC and GRE tunnels with non-SDWAN devices using Service groups. Standard tunnel configurations are in place for IPSEC or GRE tunnels as well as profiles for building tunnels. In the lab, auto IPSEC tunnels were created to Prisma Access.

3.4 Routing Integration with Non-SD-WAN Site

The purpose of this test is to identify the preferred strategy for interaction between SD-WAN and legacy sites.  These methods typically include either backhauling traffic to the DC or sending traffic directly in an underlay network such as MPLS.  Each method requires the use of dynamic routing protocols to help make the correct forwarding decision.

Recorded Results

PASS: Prisma utilizes asymmetric traffic flow correction. In this example, BR1 sdwan device sends traffic to non-sdwan BR3 across DC1 and sees the traffic return directly from BR3 via MPLS. BR1 will auto path-correct the asymmetry and send the traffic directly back to BR3 by MPLS by considering the flow of the traffic based upon the session.

 4. Lan

4.1 Router on a Stick

The purpose of this test is to demonstrate layer 2 integration with 802.1q sub-interfaces and a standard switch supporting user access.

Recorded Results

PASS: The Prisma SDWAN lan service sub-interfaces are each configured for 802.1q encapsulation under the physical port 1 of the device. The branch lan switch is directly connected via Gi0/2 and the mac address of the device can be seen in the corresponding mac address table for vlan 20.

4.2 First Hop Redundancy Protocol

The purpose of this test is to demonstrate support for standards-based router redundancy protocol VRRP.  Additionally, the VRRP deployment should have added intelligence to prevent traffic from being dropped in the event of a failure scenario.

Recorded Results

PASS: The ION edge devices utilize VRRP as their FHRP. DHCP has been configured to pass the default gateway for each service respectively to lan hosts. Each device has the same IP address configured for each respective service sub-interface for their gateways, however only the active device will respond to arp requests. There is also a track availability configured under the HA to decrement the priority by 11 if the lan physical port becomes unavailable. 

The LAN services were failed on the branch 1 primary edge device by shutting port 1. Traffic continued to flow through the secondary device, which is now the HA active in the pair, with minimal disruption. The interface was brought back online and after HA recovered, the traffic rerouted to the primary device again with minimal disruption.

 5. Security

5.1 Segmentation of User Traffic

The purpose of this test is to demonstrate how the SD-WAN solution can segment different communities of interest by isolating traffic. This may be achieved by using a specific technology (e.g. routing domains) or a combination of technologies (e.g. ZBFW and 802.1q) to achieve the desired result.

Recorded Results

PASS: Segmentation of user traffic at the branch is performed on the controller via zone-based policy bound to each interface on the edge device. Policies can then be configured that reference the security zones. Layer 2 segmentation is performed via 802.1q encapsulation. Prisma doesn't support VRF routing.

A policy was created and bound to the branch routers. Other segments could not be reached, but the device still had INET access. The policy was removed and reachability was regained.

5.2 Built-in Firewall

The purpose of this test is to demonstrate the built-in firewall capabilities of the SD-WAN appliance.  This may require the use of traditional Layer 3/Layer 4 based identification of traffic or the use of Layer 7 (DPI).  Additionally, vendors should discuss the effectiveness of their solution and if it is only locally significant or can span the entire SD-WAN fabric.

Recorded Results

PASS: Prisma SDWAN implements stateful inspection for layer 7 firewall which can be implemented over the standard 5-tuple match. Security policies can be configured to match on applications in addition to zones, services, and prefixes. In this test, a security policy was built and applied to branch 1 to block ftp data.

5.3 Service Chaining

The purpose of this test is to demonstrate redirecting traffic based on service chaining or service insertion feature.  Based on customer requirements, this policy will either need to be applied fabric wide or by region.

Recorded Results

PASS: Prisma SDWAN performs two types of service chaining for site-to-site segmentation.

1. Traffic can be forced to a local next-hop for example when traffic is backhauled to the data center, then has the next hop set as the INET firewall.

2. Configure all or specific traffic to go directly to SASE solution based on service groups referenced within a path policy.

Zenmap was used to verify the path before and after the service-chain was applied.

5.4 Prisma Access Integration

An IPSEC tunnel will be established.  This connection will be used to secure user traffic destined to the Internet from the branch. 

Recorded Results

PASS: Palo's Prisma SDWAN performs Prisma Access integration via their CloudBlade service. Once the interfaces are tagged correctly, the controller auto configures the necessary tunnels for the service for each site that is enabled. Once traffic is pointed to Access, policies can be implemented to secure connections.

 6. Application

6.1 Identification of Known Applications

The purpose of this test is to demonstrate the application identification of standard applications such as HTTP, HTTPS, FTP, SIP, and RTP.

Recorded Results

PASS: The applications are the same whether using them in path policies or zone-based firewalling. The device is layer 7 aware for application identification, but not for IPS, IDS, etc.

6.2 Identification of Custom Applications

The purpose of this test is to demonstrate the identification of custom app. Identification of custom app could be based on source/destination IP/port, protocol, or TOS/DSCP markings.

Recorded Results

PASS: Prisma has the ability to create custom applications with configuration parameters such as path affinity, idle timeout, and ingress traffic percentage to help determine the best suitable path for the application. Timers can also be adjusted per application.

Note: There was not a way to test the custom application in the lab, only to build the application in the portal.

6.3  Quality of Service (Four-Class Model)

Demonstrate QoS configuration using common strategies to classify traffic based on application, DSCP, or other parameters.  Be able to support common queuing models if required and show how it is applied on the SD-WAN device.

Recorded Results

PASS: Prisma SDWAN implements a 4 queue/4 class QoS model on both underlay and overlay. Passive bandwidth probing can also be implemented. A policy was applied to the Default QoS Simple Stack Policy Set that sets the priority to Platinum and dscp values to EF for FTP traffic. The application was identified and remarked accordingly.

6.4 Traffic Shaping and/or Policing to 10 Mbps

Demonstrate the ability to shape and/or police traffic based on a 10Mbps circuit rate. It is more common to shape traffic in an enterprise QoS deployment than it is to police traffic.  For this test, a traffic shaper of 10Mbps will be requested unless specified otherwise.

Recorded Results

PASS: Traffic for branch 2 was shaped to 10Mb for each circuit. The flows are session based so the session will be on one circuit per session. Ixia showed the traffic flows to be shaped as configured.

6.5 Brownout Detection and Re-routing

Identify brownout conditions on a transport path (e.g. Internet with 10% loss and 300ms delay) and steer critical traffic over to alternate paths (e.g. MPLS, LTE, or another Internet circuit).

Recorded Results

PASS: 10 percent loss was introduced to the INET ISP wan links. Prisma was able to see the loss and steer traffic accordingly without further policy configuration. Minimal disruption was seen on the Ixia. The impairment was removed and traffic was corrected. The Ixia did not see an impact to traffic on recovery.

6.6 Blackout Detection and Re-routing

Identify blackout conditions on a transport path (e.g. complete loss of MPLS) and steer critical traffic over to alternate path (e.g. Internet circuit).

Recorded Results

PASS: The MPLS wan connection on branch 1 router 1 via branch 1 router 2 was adminned down forcing the traffic to go through the secondary router. MOS values as well as the http and ftp traffic dropped due to the missing path but recovered quickly. The port was adminned back up and the traffic flow was normalized with minimal disruption in traffic.

6.7 Path of Last Resort

Simulate a tertiary circuit in the lab environment that is identified as a path of last resort.  Provide this connection to one of the branch sites and simulate a complete loss of primary circuits to trigger a path of last resort routing.

Recorded Results

PASS: Upon complete failure of INET or MPLS, the path of last resort (L3 Failure Path) which is typically cellular can be used for specific traffic. Additional probing is used as well as link up/down in the event that there are upstream issues. The branch DUTs do not have cellular interfaces, so the path of last resort was set to any public upon MPLS failure. The wan interface was disabled, and traffic failed to the L3 Failure Path with very little traffic disruption. Failback also showed no impact to traffic.

 7. Resiliency

7.1 Isolate Data Center 1 WAN Connections

All circuits going to DC1 will be shutdown.  Resources in DC1 will be available via the DCI connected to DC2. During this failure scenario a branch user must have access to these resources.

Recorded Results

PASS: ICMP traffic was initiated to the data lan segment gateway of DC1 from BR1. DC1 was disabled in the portal. This disables all traffic to DC1, vpns, route advertisements, tunnels and redirects traffic to DC2 then back across the DC Interconnect to the DC1 resources. There was minimal loss noticed on the traffic with no impact to MOS scores.

7.2 Hardware Failure of Device in HA

Remove power from one of the SD-WAN devices in an HA pair to simulate a hardware failure. Observe impact to traffic. Restore power to the device and determine if restoral causes any impact to traffic.

Recorded Results

PASS: ICMP traffic was initiated from BR1 to BR2 with site-to-site tunnels disabled so that all traffic traversed the DC. BR1 router 1 was rebooted. The traffic dropped a few packets before reconnecting. The Ixia flows showed minimal disruption. Preemption was enabled, so when the BR1 router 1 came back online, there was another small disruption which is typical for HA restoration.

7.3 Break HA Link Between SD-WAN Devices

 SD-WAN vendors approach HA in different manners.  Remove the HA link between an HA pair and identify how this failure scenario impacts traffic forwarding at the branch.

Recorded Results

PASS: HA is controlled by heartbeats across the controller connections. In this test we physically unplugged the controller port. Traffic showed minimal disruption while the connections reestablished. When the port was plugged back in, traffic resumed unaffected.

7.4 Loss of Control Connections

Demonstrate how an SD-WAN appliance behaves when communication to the controller/orchestrator is lost.

Recorded Results

PASS: HA is controlled by heartbeats across the controller connections. In this test we physically unplugged the controller port. Traffic showed minimal disruption while the connections reestablished. When the port was plugged back in, traffic resumed unaffected.

 8. Operations

8.1 Configuration Templates

The management component of the SD-WAN solution should be the source of truth for device configurations.  Demonstrate that an SD-WAN appliance that is connected to the controller will retain its configuration and local changes made on the appliance are prevented or overwritten by the controller.

Recorded Results

PASS: Prisma SDWAN doesn't utilize templates in the same fashion as other vendors. Instead, they use policies that are binded to the devices. These policies are sent to the devices to control the traffic just as a traditional template would. The API can also be used for site-wide changes.

8.2 One-off Configuration

An SD-WAN device has been identified as requiring a configuration outside of the deployed template.  Demonstrate how a unique configuration can be applied to a particular device without disrupting the entirety of the SD-WAN fabric.

Recorded Results

PASS: Prisma SDWAN can utilize the API for on-off configurations. This allows the user to pull the configurations, change or modify as needed and reapply. Jenga templates can be used as well. Of course you can still change policy parameters in the gui.

8.3 SD-WAN Monitoring and Reporting Tools

Highlight and show the tools available to the SD-WAN solution to monitor performance and health of the network.  This is typically done from the management device in the solution.

Recorded Results

PASS: Prisma SDWAN can show Alarms and Alerts as well as reporting with an optional addon. The portal Summary page shows information related to link quality, network insights, and application utilization as well as Alarms and MOS scores.

8.4 Third Party Integration with Netflow

Demonstrate SD-WAN support for exporting Netflow or IPFIX data to a third party collector such as Live Action, SolarWinds, or PRTG.

Recorded Results

PASS: PRTG was configured on a server VM in DC1 with IPFIX module. The branches were configured with an IPFIX profile that sends flow information to the IP address and port of the PRTG instance. PRTG was able to see the traffic and differentiate between flows. A tcpdump was performed on the branches that shows the traffic leaving the edge toward the IPFIX collector.

8.5 Third Party Integration with SNMP

Demonstrate SD-WAN support for integration SNMPv2/SNMPv3 to a third party tool such as SolarWinds or PRTG.

Recorded Results

PASS: Prisma SDWAN ION devices can successfully integrate with third-party for SNMPv2 and SNMPv3. PRTG was configured for the trap and logging server. The devices were successfully discovered with both SNMP versions and displayed statistics accordingly.

8.6 Third Party Integration with Syslog

Demonstrate SD-WAN support for exporting Syslog to a third party collector such as Splunk, SyslogNg, etc.

Recorded Results

PASS: Prisma SDWAN ION devices can successfully integrate with third-party for SYSLOG. PRTG was configured for the trap and logging collector. The devices successfully sent syslog messages and flows to PRTG.

 

All test results and artifacts can be found in Palo Alto Prisma SD-WAN POC - Test Plan - Final.pdf

Get Started with Prisma SD-WAN
Prisma SDWAN Admin Guide

Technologies