Prisma Access Default Routing: What happens if you advertise the same subnet in more than one location via BGP?

Prisma Access Default Routing what happens if you Advertise the same subnet in more than one location via BGP?

• Prisma Access Panorama Managed
• Prisma Access Remote Networks
• Prisma Access Mobile Users
• Prisma Access Service Connections

1. Prisma Access Infrastructure Learns routes from the on-premises networks like Service Connections, Remote Networks and Mobile Users just like normal BGP peers would in on-premises networks.
2. When advertising duplicate subnets in two different locations into Prisma Access you could see inconsistent/undesired behavior occuring in the infrastructure.
3. It is usually best to avoid advertising duplicate subnets into Prisma Access unless you intend to use Hot-Potato Routing which is designed for your On-Premises routers to make most of the routing decisions for traffic ingressing and egressing Prisma Access towards the Internal Network by prepending the AS-Path for each route

• Users who are connected to Mobile Users Gateway US-East state that they are having problems getting to an internal resource, in which the destination IP would be 10.100.200.35
• US-East users are able to navigate to other resources fine that are not in the 10.100.200.0/24 subnet
• Traffic logs shows everything is being allowed
• Users who are connected to US-West and US-Central aren't reporting the same problem
• Remote Networks Users within the US-East Region report same behavior as the Mobile Users in US-East
• Remote Networks Users outside of the US-East region don't report any issues.
• As seen in the diagram, the subnet 10.100.200.0/24 lives in the US-West DataCenter and the edge firewall is advertising this subnet correctly to the US-West Service Connection
• The East Datacenter Edge firewall is also advertising this same route to the US-East Service Connection
• Considering, BGP path selection process, each MU GW will be connected to it's closest Region Service Connection and the Service Connections will then be the  deciding factor as to which point the traffic will egress out of. (Same concept applies to Remote Networks)
•  Due to the above mentioned advertising the below routing decisions are being made, assuming AS-Path are the same across the instance, in this scenario:

1. From US-East user: US-East GW -> US-East SC -> US-East Datacenter -> traffic dies here
   1. Based on the routing table for US-East SC, we see that it had received the same route from the US-East Datacenter via EBGP and it also received the route from US-West SC via IBGP. Both paths were the same except for the EBGP over IBGP selection, so the EBGP path was preferred. The traffic dies when entering the Datacenter Network for various routing reasons
2. From US-Central user: US-Central GW -> US-Central SC -> US-West SC -> US-West Datacenter
   1. In this scenario, the Central SC received the routes from both East and West  SC's, but West had a better local preference so the Central SC installed the US-West SC's routing it was given
3. From US-West user: US-West GW -> US-West SC -> US-West Datacenter
   1. US-West is similar to US-East SC, as the EBGP route was chosen over the learned IBGP route

If you are using Panorama Managed, you can leverage the Troubleshooting Commands to see what the routing table looks for your Service Connections and Remote Networks. Note this is only for BGP enabled sites.

Path for the Troubleshooting Commands:
Panorama>Cloud Services>Configuration>Service Setup>Troubleshooting Commands>Routing Information

BGP Path Selection Process are evaluated in the following order:

• Weight
• Local Preference
• Locally Originated
• AS-Path
• Origin
• MED
• eBGP over iBGP
• Lowest IGP Metric to neighbor
• Older Route
• Lowest Router ID