Routing for Service Connection Traffic
Table of Contents
Routing for Service Connection Traffic
How Prisma Access routes its service connection traffic from mobile users and
remote network connections, and the different modes you can use.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
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.
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 works as described in this
section. 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 connections and remote network connections. When
you use BGP routing for your connections, your organization’s network learns BGP
information from Prisma Access.
Before you decide which service connection
routing to use, you should understand how Prisma Access routes traffic between
mobile users, remote networks, and service connections, because the routing used by
mobile user traffic and remote network traffic between service connections is different.
Mobile User-service connection
routing—The mobile user connection forms an IPSec tunnel with the nearest service
connection. Prisma Access uses iBGP for internal routing and eBGP to peer with
the customer premises equipment at the data center. The following diagram shows mobile
users in Regions 1 and 2 being routed to the respective service connections in that
region. Mobile users in Region 1 are accessing applications A and B
located at Data Center 1. If your organization’s network uses BGP routing for their
service connections and a service connection experiences an ISP failure at Data Center
1, Prisma Access detects the failure and routes the traffic for applications
A and B to Data Center 2 after BGP convergence, providing redundancy
to your network’s data centers.
Prisma Access uses the following timing with BGP when it detects a failure:
If you configure BGP routing and have enabled tunnel monitoring, the shortest
default hold time to determine that a security parameter index (SPI) is failing is
the tunnel monitor, which removes all routes to a peer when it detects a tunnel
failure for 15 consecutive seconds. In this way, the tunnel monitor determines the
behavior of the BGP routes. If you do not configure tunnel monitoring, the hold
timer determines the amount of time that the tunnel is down before removing the
route. Prisma Access uses the default BGP HoldTime value of 90 seconds as
defined by RFC 4271, which is the maximum wait time before Prisma Access
removes a route for an inactive SPI. If the peer BGP device has a shorter configured
hold time, the BGP hold timer uses the lower value. When the secondary tunnel is
successfully installed, the secondary route takes precedence until the primary
tunnel comes back up. If the primary and secondary are both up, the primary route
takes priority.
Remote Network-service connection
routing—Prisma Access creates a full mesh network with other remote
networks and service connections. As with mobile users, Prisma Access uses iBGP
for its internal routing and eBGP to peer with customer premises equipment to exchange
routes. If a user in Branch 1 is accessing application A from Data Center 1 in
your organization’s data center and the link between Branch 1 and Data Center 1 goes
down, Prisma Access routes the traffic for application A to Data Center
2 after BGP convergence.
After you understand Prisma Access service connection routing and how it
relates to your network, you can choose one of the following routing modes for
service connections:
-
Default routing—This is the default 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
How Prisma Access default routing works for service connections.
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 divides the subnets into Class C /24
address blocks 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 blocks of /24 subnets 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 mobile user IP address pool: 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 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.
You can view the community string by selecting and find the Community field in the
Peer tab.
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.
Prisma Access Hot Potato Routing
Learn about how hot potato routing works for Prisma Access service
connections.
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 |
In hot potato routing mode, Prisma Access allows you to specify a backup service
connection during onboarding. Specifying a Backup SC informs
Prisma Access to use 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 SC 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 SC of US-E for the US-W service connection, and
vice versa, to ensure symmetric routing.
