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 divides the
routes into blocks of /24 before advertising them.
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.
