Prisma Access
Dynamic Routing Considerations for Service Connections
Table of Contents
Expand All
|
Collapse All
Prisma Access Docs
-
5.2 Preferred and Innovation
- 5.2 Preferred and Innovation
- 5.1 Preferred and Innovation
- 5.0 Preferred and Innovation
- 4.2 Preferred
- 4.1 Preferred
- 4.0 Preferred
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
-
-
-
-
- Allocate Licenses for Prisma Access (Managed by Strata Cloud Manager)
- Plan Service Connections for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Add Additional Locations for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Enable Available Add-ons for Prisma Access (Managed by Strata Cloud Manager)
- Enable Dynamic Privilege Access for Prisma Access (Managed by Strata Cloud Manager)
- Search for Subscription Details
- Share a License for Prisma Access (Managed by Strata Cloud Manager) and Add-ons
- Increase Subscription Allocation Quantity
-
- Activate a License for Prisma Access (Managed by Strata Cloud Manager) and Prisma SD-WAN Bundle
-
- Onboard Prisma Access
-
4.0 & Later
- 4.0 & Later
- 3.2 Preferred and Innovation
- 3.1 Preferred and Innovation
- 3.0 Preferred and Innovation
- 2.2 Preferred
- Prisma Access China
-
- Set Up Prisma Access
- Configure the Prisma Access Service Infrastructure
- Remote Networks: IPSec Termination Nodes and Service IP Addresses
- Remote Networks: IP Address Changes Related To Bandwidth Allocation
- Remote Networks: Service IP Address and Egress IP Address Allocation
- API Examples for Retrieving Prisma Access IP Addresses
- Get Notifications When Prisma Access IP Addresses Change
- Prisma Access Zones
- DNS for Prisma Access
- High Availability for Prisma Access
-
- Enable ZTNA Connector
- Delete Connector IP Blocks
- Set Up Auto Discovery of Applications Using Cloud Identity Engine
- Private Application Target Discovery
- Security Policy for Apps Enabled with ZTNA Connector
- Monitor ZTNA Connector
- View ZTNA Connector Logs
- Preserve User-ID Mapping for ZTNA Connector Connections with Source NAT
-
- Enable Dynamic Privilege Access for Prisma Access Through Common Services
- Authorize User Group Mapping in Cloud Identity Engine for Dynamic Privilege Access
- Enable the Access Agent
- Set Up the Agent Infrastructure for Dynamic Privilege Access
- Create a Snippet
- Create a Project
- Traffic Steering for Dynamic Privilege Access
- Push the Prisma Access Agent Configuration
- Download the Dynamic Privilege Access Enabled Prisma Access Agent Package
-
- Install the Prisma Access Agent
- Log in to the Dynamic Privilege Access Enabled Prisma Access Agent
- Change Preferences for the Dynamic Privilege Access Enabled Prisma Access Agent
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Location
- Switch to a Different Project
- Connect the Dynamic Privilege Access Enabled Prisma Access Agent to a Different Server
- Disable the Dynamic Privilege Access Enabled Prisma Access Agent
- Switch Between the Prisma Access Agent and GlobalProtect App
- View and Monitor Dynamic Privilege Access Users
- View and Monitor Dynamic Privilege Access Projects
- App Acceleration in Prisma Access
-
-
- Planning Checklist for GlobalProtect on Prisma Access
- Set Up GlobalProtect Mobile Users
- GlobalProtect — Customize Tunnel Settings
- GlobalProtect — Customize App Settings
- Ticket Request to Disable GlobalProtect
- GlobalProtect Pre-Logon
- GlobalProtect — Clientless VPN
- Monitor GlobalProtect Mobile Users
- How the GlobalProtect App Selects Prisma Access Locations for Mobile Users
- Allow Listing GlobalProtect Mobile Users
-
- Explicit Proxy Configuration Guidelines
- GlobalProtect in Proxy Mode
- GlobalProtect in Tunnel and Proxy Mode
- Private IP Address Visibility and Enforcement for Agent Based Proxy Traffic
- SAML Authentication for Explicit Proxy
- Set Up Explicit Proxy
- Cloud Identity Engine Authentication for Explicit Proxy Deployments
- Proxy Mode on Remote Networks
- How Explicit Proxy Identifies Users
- Explicit Proxy Forwarding Profiles
- PAC File Guidelines
- Explicit Proxy Best Practices
- Monitor and Troubleshoot Explicit Proxy
- Block Settings for Explicit Proxy
- Use Special Objects to Restrict Explicit Proxy Internet Traffic to Specific IP Addresses
- Access Your Data Center Using Explicit Proxy
- App-Based Office 365 Integration with Explicit Proxy
- Configure Proxy Chaining with Blue Coat Proxy
- IP Address Optimization for Explicit Proxy Users- Proxy Deployments
- DNS Resolution for Mobile Users—Explicit Proxy Deployments
- View User to IP Address or User Groups Mappings
- Report Mobile User Site Access Issues
- Enable Mobile Users to Access Corporate Resources
-
-
- Planning Checklist for Remote Networks
- Allocate Remote Network Bandwidth
- Onboard a Remote Network
- Connect a Remote Network Site to Prisma Access
- Enable Routing for Your Remote Network
- Onboard Multiple Remote Networks
- Configure Remote Network and Service Connection Connected with a WAN Link
- Remote Networks—High Performance
- Integrate a Shared Desktop VDI with Prisma Access Using Terminal Server
-
- Multitenancy Configuration Overview
- Plan Your Multitenant Deployment
- Create an All-New Multitenant Deployment
- Enable Multitenancy and Migrate the First Tenant
- Add Tenants to Prisma Access
- Delete a Tenant
- Create a Tenant-Level Administrative User
- Sort Logs by Device Group ID in a Multitenant Deployment
-
- Add a New Compute Location for a Deployed Prisma Access Location
- How BGP Advertises Mobile User IP Address Pools for Service Connections and Remote Network Connections
- Proxy Support for Prisma Access and Strata Logging Service
- Block Incoming Connections from Specific Countries
- Prisma Access for No Default Route Networks
-
-
- Default Routes With Prisma Access Traffic Steering
- Traffic Steering in Prisma Access
- Traffic Steering Requirements
- Default Routes with Traffic Steering Example
- Default Routes with Traffic Steering Direct to Internet Example
- Default Routes with Traffic Steering and Dedicated Service Connection Example
- Prisma Access Traffic Steering Rule Guidelines
- Configure Zone Mapping and Security Policies for Traffic Steering Dedicated Connections
- Configure Traffic Steering in Prisma Access
- Preserve User-ID and Device-ID Mapping for Service Connections with Source NAT
-
- Prisma Access Internal Gateway
-
- Configure Privileged Remote Access Settings
- Set Up the Privileged Remote Access Portal
- Configure Applications for Privileged Remote Access
- Set Up Privileged Remote Access Profiles
- Define Permissions for Accessing Privileged Remote Access Apps
- Configure Split Tunneling for Privileged Remote Access Traffic
- Manage Privileged Remote Access Connections
- Use Privileged Remote Access
-
- Integrate Prisma Access With Other Palo Alto Networks Apps
- Integrate Third-Party Enterprise Browser with Explicit Proxy
-
-
- Connect your Mobile Users in Mainland China to Prisma Access Overview
- Configure Prisma Access for Mobile Users in China
- Configure Real-Name Registration and Create the VPCs in Alibaba Cloud
- Attach the CEN and Specify the Bandwidth
- Create Linux Instances in the Alibaba Cloud VPCs
- Configure the Router Instances
- Onboard the GlobalProtect Gateway and Configure the Prisma Access Portal
-
-
-
- INC_CIE_AGENT_DISCONNECT
- INC_CIE_DIRECTORY_DISCONNECT
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_GW_USER_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_GLOBALPROTECT_PORTAL_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_ALL_PA_LOCATIONS
- INC_PORTAL_CLIENTLESS_VPN_AUTH_ TIMEOUT_FAILURES_COUNT_EXCEEDED_ ABOVE_BASELINE_PER_PA_LOCATION
- INC_MU_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_MU_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_MU_DNS_SERVER_UNREACHABLE_ PER_PA_LOCATION
- INC_RN_AUTH_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_AUTH_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_DNS_SERVER_UNREACHABLE_ALL_ PA_LOCATIONS
- INC_RN_DNS_SERVER_UNREACHABLE_PER_ PA_LOCATION
- INC_RN_ECMP_TUNNEL_RTT_EXCEEDED_ BASELINE
- INC_RN_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SECONDARY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_RN_SITE_CAPACITY_PREDICTION
- INC_SC_PRIMARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SECONDARY_WAN_TUNNEL_RTT_ EXCEEDED_BASELINE
- INC_SC_SITE_CAPACITY_PREDICTION
-
- INC_CERTIFICATE_EXPIRY
- INC_GP_CLIENT_VERSION_UNSUPPORTED
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_CAPACITY
- INC_MU_IP_POOL_BLOCK_UTILIZATION_ EXCEEDED_THRESHOLD
- INC_PA_INFRA_DEGRADATION
- INC_PA_SERVICE_DEGRADATION_PA_LOCATION
- INC_PA_SERVICE_DEGRADATION_RN_ SITE_CONNECTIVITY
- INC_PA_SERVICE_DEGRADATION_SC_ CONNECTIVITY
- INC_RN_ECMP_BGP_DOWN
- INC_RN_ECMP_BGP_FLAP
- INC_RN_ECMP_PROXY_TUNNEL_DOWN
- INC_RN_ECMP_PROXY_TUNNEL_FLAP
- INC_RN_ECMP_TUNNEL_DOWN
- INC_RN_ECMP_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_BGP_FLAP
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_PRIMARY_WAN_TUNNEL_DOWN
- INC_RN_PRIMARY_WAN_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_BGP_DOWN
- INC_RN_SECONDARY_WAN_BGP_FLAP
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_RN_SECONDARY_WAN_TUNNEL_DOWN
- INC_RN_SECONDARY_WAN_TUNNEL_FLAP
- INC_RN_SITE_DOWN
- INC_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_RN_SPN_LONG_DURATION_CAPACITY_EXCEEDED _THRESHOLD
- INC_RN_SPN_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_SC_PRIMARY_WAN_BGP_DOWN
- INC_SC_PRIMARY_WAN_BGP_FLAP
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_PRIMARY_WAN_TUNNEL_DOWN
- INC_SC_PRIMARY_WAN_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_BGP_DOWN
- INC_SC_SECONDARY_WAN_BGP_FLAP
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_PROXY_TUNNEL_FLAP
- INC_SC_SECONDARY_WAN_TUNNEL_DOWN
- INC_SC_SECONDARY_WAN_TUNNEL_FLAP
- INC_SC_SITE_DOWN
- INC_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- INC_SC_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN
- INC_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- INC_ZTNA_CONNECTOR_CPU_HIGH
- INC_ZTNA_CONNECTOR_MEMORY_HIGH
- INC_ZTNA_CONNECTOR_TUNNEL_DOWN
-
- AL_CIE_AGENT_DISCONNECT
- AL_CIE_DIRECTORY_DISCONNECT
- AL_MU_IP_POOL_CAPACITY
- AL_MU_IP_POOL_USAGE
- AL_RN_ECMP_BGP_DOWN
- AL_RN_ECMP_BGP_FLAP
- AL_RN_PRIMARY_WAN_BGP_DOWN
- AL_RN_PRIMARY_WAN_BGP_FLAP
- AL_RN_PRIMARY_WAN_TUNNEL_DOWN
- AL_RN_PRIMARY_WAN_TUNNEL_FLAP
- AL_RN_SECONDARY_WAN_BGP_DOWN
- AL_RN_SECONDARY_WAN_BGP_FLAP
- AL_RN_SECONDARY_WAN_TUNNEL_DOWN
- AL_RN_SECONDARY_WAN_TUNNEL_FLAP
- AL_RN_SITE_DOWN
- AL_RN_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_RN_SITE_LONG_DURATION_EXCEEDED_ CAPACITY
- AL_RN_SPN_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_PRIMARY_WAN_BGP_DOWN
- AL_SC_PRIMARY_WAN_BGP_FLAP
- AL_SC_PRIMARY_WAN_TUNNEL_DOWN
- AL_SC_PRIMARY_WAN_TUNNEL_FLAP
- AL_SC_SECONDARY_WAN_BGP_DOWN
- AL_SC_SECONDARY_WAN_BGP_FLAP
- AL_SC_SECONDARY_WAN_TUNNEL_DOWN
- AL_SC_SECONDARY_WAN_TUNNEL_FLAP
- AL_SC_SITE_DOWN
- AL_SC_SITE_LONG_DURATION_CAPACITY_ EXCEEDED_THRESHOLD
- AL_SC_SITE_LONG_DURATION_EXCEEDED_CAPACITY
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN
- AL_ZTNA_CONNECTOR_APP_STATUS_DOWN_PARTIAL
- AL_ZTNA_CONNECTOR_CPU_HIGH
- AL_ZTNA_CONNECTOR_MEMORY_HIGH
- AL_ZTNA_CONNECTOR_TUNNEL_DOWN
- New Features in Incidents and Alerts
- Known Issues
Dynamic Routing Considerations for Service Connections
Learn how to route data for service connection traffic.
Where Can I Use This? | What Do I Need? |
---|---|
|
|
How It Works — Routing Service Connection Traffic
Prisma Access uses BGP for dynamic routing, and uses BGP path selection
to install routes in the route table. When Prisma Access routes traffic to your
headquarters or data center using service connections, it uses routing methods that
direct that traffic effectively. Prisma Access uses a default routing model that was
designed to fit the majority of network deployments; however, not all organization’s
networks are the same. To fit a wider range of deployments, Prisma Access allows you
choose another mode for service connection routing. The following sections describe
the BGP routing methods that Prisma Access uses, along with the factors you need to
consider in your organization’s network before changing Prisma Access’ default
method of service connection routing.
Changing the Prisma Access service connection routing method requires a thorough
understanding of your organization’s topology and routing devices, along with an
understanding of how Prisma Access routing works as described in this section.
We recommend that you read this section carefully before changing the routing
method from the default setting.
Prisma Access supports static routing and dynamic routing using BGP for service and
remote network connections; this section assumes that you use BGP routing for your
Prisma Access deployments. When you select BGP routing, your organization’s network
learns BGP information from Prisma Access.
Routing Modes for Service Connections
You can choose from the following routing modes with Prisma Access:
- Default routing—This is the current routing model that Prisma Access uses.Use this routing mode if you want Prisma Access to use BGP best path-selection mechanisms without adjusting any of the BGP attributes. In this mode, Prisma Access will honor any attribute advertised by the customer premises equipment (CPE).
- Hot Potato routing—Prisma Access hands off the traffic as quickly as it can to your organization’s network.Use this routing method if you want your organization’s network to perform the majority of routing decisions.
Prisma Access Default Routing
The following figure shows an example of Prisma Access routing service connection
traffic in default routing mode. The organization’s network has three separate
networks in three data centers and does not have a backbone connecting the networks.
In default routing mode, mobile user pools are advertised equally on the three
networks, as shown at the bottom of the figure.
Note that, when Prisma Access advertises mobile user routes, it before advertising
them; thus, it advertises the /20 mobile user subnets in chunks of /24 as prefixes
are consumed by the gateways.
Make a note of how Prisma Access uses BGP route advertisements:
- Prisma Access does not adjust the default BGP attributes for mobile user advertised routes (Prisma Access adds its AS number to the route advertisements).
- Prisma Access advertises mobile user routes in and adds BGP community values in the routes it advertises through the service connection. The following figure shows a mobile user deployment with three service connections and three different IP address blocks specified for the : 192.168.64.0/20 for the Asia, Australia & Japan region, 192.168.72.0/20 for the Africa, Europe & Middle East region, and 192.168.48.0/20 for the North America & South America region. Prisma Access divides these routes into block of /24 and advertises them with an Prisma Access’ AS number of 65534, but also appends the BGP community values to the advertisements (Z for Asia, Y for EU, and X for US). Those routes are shown in the middle of the figure. In this way, you can differentiate service connections in your network, even though Prisma Access assigns the same AS number to them.

The following figure shows a more common network with a full-mesh eBGP backbone. The
figure shows the routes that Prisma Access has learned from your organization’s
network on the top right. Note the extra routes that Prisma Access has learned
through the Prisma Access backbone (iBGP) and your organization’s backbone
(eBGP).
For traffic between mobile users in the North America & South
America region (US in the diagram) and the data center in your
organization’s Africa, Europe & Middle East region (EU in
the diagram), Prisma Access chooses the path through the EU service connection
because it prefers routes with a shorter AS-PATH.

In deployments with a full-mesh eBGP backbone, asymmetry can arise when Prisma Access
cannot reach a particular data center due to an ISP/CPE failure at the customer’s
data center. The following figure shows what could happen when the link to the EU
service connection goes down. Your network detects the link failure and builds a new
route table for AS 200. Traffic from the US service connection to AS 200 uses the
path through AS 100 because the eBGP route for your backbone between AS 200 and AS
100 is preferred to the iBGP route between service connections EU and US. However,
return traffic is not guaranteed through the same path because the on-premises CPE
can choose either path (shown in red) to return the traffic.

The previous examples show a network whose routes have not been aggregated (that is,
you have not performed route summarization before you send the BGP route
advertisements to Prisma Access). The following example shows a network that
summarizes its routes to 10.0.0.0/8 before sending to Prisma Access. If you select
default routing, this configuration can lead to asymmetric routing issues, because
Prisma Access cannot determine the correct return path from the summarized
routes.
If your Prisma Access deployment has Remote Networks, Palo Alto Networks does not
recommend the use of route summarization on Service Connections. Route
summarization on service connections is for Mobile Users deployments only.

If you use route aggregation for mobile users, we strongly recommend that you enable
hot potato routing instead of default routing, where Prisma Access hands off the
traffic as quickly as possible to your organization’s network. In addition, we
recommend that you select a Backup SC as described in the
following section for each service connection to have a deterministic routing
behavior.
Hot Potato Routing
When you select Hot Potato Routing, Prisma Access egresses the
traffic bound to service connections/data centers from its internal network as
quickly as possible.
With hot potato routing, Prisma Access prepends the AS path (AS-PATH) to the BGP
prefix advertisements sent from gateways. This prepending is performed when the
prefixes are advertised out of the service connection to your organization’s
on-premises CPE. Prisma Access prepends the AS-PATHs so that your CPE gives the
correct preference to the primary and secondary tunnels, so that if the primary
tunnel goes down, your CPE chooses the secondary tunnel as the backup.
If you specified a different IP address for the secondary (backup) BGP peer, Prisma
Access adds more prepends based on the tunnel type, as shown in the following table.
Prefix Type | Service Connection Tunnel Type | Number of As-Path Prepends | Total AS-PATHs Seen on the CPE |
---|---|---|---|
Gateway prefixes from primary service connection | Primary or Secondary tunnel with the same BGP peer IP address | 0 | 1 |
Gateway prefixes from backup service connection | Primary or Secondary tunnel with the same BGP peer IP address | 3 | 4 |
Gateway prefixes from all other service connections | Primary or Secondary tunnel with the same BGP peer IP address | 6 | 7 |
Gateway prefixes from primary service connection | Secondary tunnel with a different BGP peer IP address | 1 | 2 |
Gateway prefixes from backup service connection | Secondary tunnel with a different BGP peer IP address | 4 | 5 |
Gateway prefixes from all other service connections | Secondary tunnel with a different BGP peer IP address | 7 | 8 |
Specify a Backup Service Connection so that Prisma Access to
uses that service connection as the backup when a service connection link fails.
The following figure shows a hot potato routing configuration for traffic between the
US service connection and AS 200, with the EU service connection configured as the
Backup Service Connection of the US connection. Using hot
potato routing, Prisma Access sends the traffic from its closest exit path through
the US service connection. The return traffic takes the same path through AS100
because this path has a shorter AS-PATH to the mobile user pool in the US location.
Prisma Access prepends the AS-PATH to its prefix advertisements depending on whether
the tunnel is a primary tunnel, a backup tunnel, or not used for either primary or
backup.

Because you have set up a backup service connection, if the link to the US service
connection goes down, hot potato routing sends the traffic out using its shortest
route through the EU service connection. This routing scenario also applies to
networks that use route aggregation.

You can also use backup service connections for multiple service connections in a
single region. The following figure shows a Prisma Access deployment with two
service connections in the North America region. In this case, you specify a
Backup Service Connection of US-E for the US-W service
connection, and vice versa, to ensure symmetric routing.
