Can I manipulate routes from Prisma to a data center using BGP MED values

[dintymoore]

Our HQ currently uses dual ISPs for internet access and has VPN tunnels to Prisma configured across both ISP circuits as primary and secondary VPN tunnels for a single service connection.  At HQ both tunnels terminate at a Palo Alto 1420 NGFW HA pair.  We are using BGP to exchange routing information between Prisma and the 1420. On the 1420 we have 2 virtual routers running BGP instances, one for each of the Prisma VPN tunnels.  We are currently advertising the HQ networks to Prisma w/o MED values in both BGP instances and letting Prisma handle prioritizing the routes based on the status of the primary and secondary VPN tunnels.  The 2 1420 BGP instances are also neighbors with each other.

We need to make the current secondary tunnel our new primary tunnel and our current primary tunnel our new secondary tunnel.  This must be done non-disruptively. 

Here is a proposed migration scenario.  Let's call our current service connection SC-A.  We have a spare, unused Prisma service connection available to us, which I'll call SC-B.  We create SC-B and configure a primary VPN tunnel for it using the settings we currently have for SC-A's secondary VPN tunnel.  When the secondary VPN tunnel  to SC-A is deactivated and the primary VPN tunnel to SC-B is activated on the 1420 we want all Prisma traffic to flow through SC-B. 

Here is how I propose to do that.   In each of the 1420's BGP instances we advertise the HQ routes to Prisma with pre-assigned MED values.  To SC-A we advertise them with MED 200 and to  SC-B we advertise them with MED 100.  To ensure that traffic out to Prisma is symmetric we use BGP local preference values to send traffic to Prisma out SC-B.

Will Prisma honor the MED values we feed it, or will it override the MED values we provide and use its own internal logic to determine which service connection to use to get traffic to our HQ? 

Or maybe I'm overthinking this whole issue and there is a simpler, non-disruptive way to switch the primary and secondary VPN tunnels. 

[dintymoore]

I did some testing and it seems a safe bet that feeding Prisma MED values from our CPE equipment won't change Prisma's routing decisions, whereas advertising the less-preferred route with an AS prepend does change the routing decisions.  I couldn't test with multiple service connections but did test with the primary and secondary VPN tunnels on our existing service connection.  First, I tried feeding Prisma MED values that would reverse the priority of the two tunnels.  Prisma ignored the MED values we provided.  Then I used the AS prepend method and the route through the secondary tunnel ended up in the Prisma routing table rather than the route through the primary tunnel.  I suspect that using two service connections would still lead to Prisma ignoring our MED values and applying a metric of 100 to both routes, since both come through primary tunnels.  To get Prisma to prefer routing through one service connection to the same destination over another, I guess the solution is to use AS prepends on the Prisma side and possibly local preference on the CPE side to ensure symmetric traffic flow.  Anyone know differently?

[nikoolayy1 · Accepted solution]

This sounds like what is described in the "Hot potato routing" with the AS prepend. I suggest seeing the article and video:

Routing for Service Connection Traffic

Best Practices for Prisma Access Routing & Logging

Service Connection Multi-Cloud Redundancy

Other than that if you have Prisma SD-WAN ION device it allows you fine grade control as you can send important traffic on tunnel one/ISP1 but still utilize tunnel two/ISP2. 

[dintymoore]

Thanks for the background info!  It looks like hot potato routing would do essentially the same thing as my AS prepend approach on our CPE.   Switching to hot potato routing isn't a good long-term solution for us, however.  We only need to override the behavior of Prisma's default routing mode long enough to exchange places between the primary and secondary VPN tunnels to our headquarters without any significant traffic interruptions.  If we can temporarily have two service connections to our headquarters, each with a primary VPN tunnel, it appears we can dictate to Prisma via AS prepends which tunnel to use to reach our headquarters networks.  That will work well enough for our temporary scenario.