Prisma SD-WAN Articles

1. Recommended Design In this section, we outline the recommended design for terminating Service Connection with Prisma SD-WAN, emphasizing traffic symmetry. The above design includes the following components and connections as depicted in the reference network diagram: Prisma SD-WAN IONs: Two ION devices in each data center to handle SD-WAN functionality. Core Router: The central router within the data center for core network routing. The service connection from Prisma Access terminates on the SD-WAN IONs in the data center. The Service Connection is connected to both Prisma SD-WAN IONs using Edge BGP peer configuration. This peer type allows the data-center ION to learn IP prefixes from the Prisma Access and split the prefixes if needed (if we are learning the same prefixes from remote branches) when advertising back to the Core Router. Each ION device is connected to the Core Router using Core Peer configuration. This configuration enables the automatic generation of route-maps by the Cloud Manager to control route advertisement and learning. 2. Configuration 2.1. Edge Peer When setting up service connections on Prisma SD-WAN ION devices, you may need to ensure that all necessary routes are advertised back to Prisma Access over Service Connection. By default, an outbound route-map on the edge peer will restrict route advertisements. To advertise routes to Prisma Access over the service connection, remove the outbound route-map from the edge peer configuration. This allows the edge peer to send all routes without filtering. 2.2. Service Connection To maintain symmetry of return traffic from IONs in the data center to the service connection, you need to modify the default Prisma Access routing behavior to allow asymmetric flows. By default, Prisma Access requires symmetric routing for traffic flows on service connections, which can lead to asymmetric flows being dropped at the corporate-access nodes. Adjusting your Prisma Access settings to permit asymmetric flows ensures proper handling of return traffic between the data center IONs and the service connection. 3. Traffic Flow Scenarios The following scenarios illustrate how traffic flows in the recommended network design. 3.1. Mobile User Accessing Private Application in Data Center 3.1.1. Inbound Traffic A mobile user attempts to access a private application hosted in the data center. The traffic is routed through Prisma Access and reaches the data center via the service connection. The service connection terminates at the SD-WAN ION. As shown above in the configuration, we have changed the outbound route-map for the edge peer so that the ION device will advertise the routes to the Service Connection. Service Connection, which has learned the routes from the SD-WAN ION, forwards the traffic to the ION device and ION device will forward the traffic to the Core Router. The Core Router sends the traffic to the destined application. 3.1.2. Return Traffic The return traffic from the application is sent back to the Core Router. The Core Router forwards the return traffic to the SD-WAN ION. The SD-WAN sends the traffic back to Prisma Access over the service connection. Finally, Prisma Access routes the return traffic back to the mobile user. 3.2. Remote Branch User Accessing Private Application in Data Center via Prisma Access 3.2.1. Inbound Traffic A remote branch user attempts to access a private application in the data center. Depending on the policy configuration at the remote branch, the traffic is routed through Prisma Access via the Prisma Access tunnel from the branch. The traffic reaches the data center's SD-WAN IONs via the service connection. The DC ION Devices, having learned the routes from the Core Router, forwards the traffic to the Core Router. The Core Router sends the traffic to the destined application. 3.2.2. Return Traffic The return traffic from the application is sent back to the Core Router. The Core Router forwards the return traffic to the SD-WAN ION.. The return traffic reaches the ION device. The ION device forwards the traffic back to Prisma Access over the service connection because when we receive the inbound flow, the session was recorded and we follow the same path for the outbound flow for the existing session. Prisma Access routes the return traffic back to the remote branch over the Prisma Access tunnel. 3.3. Remote Branch User Accessing Private Application in Data Center over Secure Fabric Tunnels 3.3.1. Inbound Traffic A remote branch user attempts to access a private application in the data center directly (depending on policy configuration) over secure fabric tunnels. The traffic is received by the ION device in the data center. The ION device sends the traffic to the Core Router. The Core Router forwards the traffic to the destined application. 3.3.2. Return Traffic The return traffic from the application is sent back to the Core Router. The Core Router forwards the return traffic to the ION device The ION device in the data center sends the traffic back to the remote site over the secure fabric tunnel because when we receive the inbound flow, the session was recorded and we follow the same path for the outbound flow for the existing session.

Introduction Building upon the strong application identification and performance characterization capabilities of Prisma SD-WAN, App SLA Assurance enables a flexible framework for the both Application and Network SLAs. By first understanding the application using Palo Alto Networks App-ID technology, Prisma SD-WAN is able to identify thousands of applications out of the box in addition to custom L3/L4 and L7 application definitions. By combining the application and network performance characterization with the control of the Prisma SD-WAN policy model, network operators are able to deliver an exceptional end-user experience while simplifying day 2 operations. Real-User Performance Characterization After an application is identified the performance of each real user session is characterized including: Initialization Success / Failure Rate - TCP 3-way handshake Transaction Success / Failure Rate - TCP Retransmission Application Round Trip Time Application Server Response Time Application Transaction Time Voice MOS Voice / Video Packet Loss Voice / Video Jitter Link Quality Metrics Additionally there are two "Always On" technologies used to determine point to point transport (IE Link Quality) performance as well as service performance. For Link Quality the following metrics are measured: Round Trip Latency Packet Loss (Bi-directional) Jitter (Bi-directional) Link MOS (Bi-directional) Bandwidth Consumption (Bi-directional) Service Probing The second "Always On" performance characterization method uses defined (default and custom) service probing for multiple protocols including ICMP, DNS, HTTP, HTTPS and measures: HTTP/S Response Time HTTP/S Response Code HTTP/S Response String HTTP/S Response Success / Failure DNS Response Success / Failure DNS Transaction Time ICMP Packet Loss ICMP Round Trip Latency ICMP Round Trip Jitter The default probes measure: ICMP response to Google G-suite : apps.google.com ICMP response to CloudFlare DNS : 1.1.1.1 ICMP response to Microsoft Teams : teams.microsoft.com These probes enable the system to determine the per path performance to a specific service endpoint which is then used to make the most informed path selection decision. Up to 8 probes can be configured per Circuit and can be sent on any combination of Prisma SD-WAN overlay, Standard VPN overlay, and Underlay. Path Selection The various real time metrics are each fed back into path selection and used to protect existing application sessions by moving active traffic around issues as well as placing new application sessions onto the best performing path. The path selection intent is specified in path policy rules. Quality-Based Control The definition of application and network SLAs is controlled via the Prisma SD-WAN Performance Policy. In Performance Policy desired actions are first selected. These include: Generate Incident - If the SLA parameters are violated an incident will be created. Move Flows - Move new and existing flows away from paths that do not meet the SLA. Forward Error Correction - If a SLA compliant path is not available then invoke adaptive FEC to correct packet loss. Packet Duplication - Duplicate the packets of a flow on up to 3 paths. Visibility - Link Quality SLAs configured will be reflected on the Link Quality time series charts. Furthermore, detailed match criteria enable flexible tuning of the SLA parameters: Application IDs - One or more App-IDs Application Transfer Types Circuit Categories Path Types Service & DC Groups SLA Type - Application, Network, Probe Summary Prisma SD-WAN Application SLA assurance provides out of the box protection and can be tuned to most nuanced needs of any enterprise, thus enabling the delivery of an exceptional end user application experience while simplifying day 2 operations. For step by step guides on how to configure App SLA rules please review the Prisma SD-WAN Admin Guide: https://docs.paloaltonetworks.com/prisma/prisma-sd-wan/prisma-sd-wan-admin

This video will walk you through some of the upcoming changes to the Prisma SD-WAN user interface as it becomes a part of the Strata Cloud Manager: For an introductory guide to Prisma SD-WAN in the Strata Cloud Manager please visit here. For a detailed guide for all products in the Strata Cloud Manager please visit here. For all of the Prisma SD-WAN content please visit here. For the Pre-Migration Prisma SD-WAN admin guide please visit here. For an overview of the tenant requirements please visit here (customer login required).

This document contains highlights of new features and capabilities available through the Prisma SD-WAN (formerly CloudGenix) Portal. Prisma SD-WAN recommends upgrading to the latest release at all times to take advantage of new features, software enhancements, and bug fixes. Highlights include: Link Quality Metrics on the Dashboard Flow Browser Enhancement to Link to Policy Rules Quick Filters Preserved Across Activity Pages Learn more here.