Prisma Access Routing: Default (Cold Potato) vs. Hot Potato & Internals Quiz

The core difference between Prisma Access Default Routing and Hot Potato Routing lies in how long traffic stays on the optimized Prisma Access backbone before exiting to the public internet. This choice impacts performance, latency, and the source IP address seen by the destination. This page also explains how Prisma Access makes these routing decisions and manages BGP interactions.

1. Prisma Access Default Routing (Cold Potato)

Concept: Keep traffic on the Prisma Access backbone for as long as possible, egressing from a PoP near the final destination.

Traffic Flow & Behavior:

1. User traffic enters the nearest Prisma Access PoP (Ingress PoP).
2. Security policies are applied.
3. Prisma Access routes the traffic across its internal backbone towards a PoP geographically closest to the traffic's final destination (Egress PoP). (See "How Prisma Access Optimizes Routing" below for details on this step).
4. Traffic exits Prisma Access from this Egress PoP, using a Service IP from that PoP's region. The destination sees a source IP close to its own location.

Benefits:

• Optimized Performance: Leverages Palo Alto Networks' backbone for lower latency and consistent user experience.
• Security Consistency: Traffic inspected across the backbone.
• Predictable Routing: More controlled path within the Prisma Access environment.

When Used:

This is the standard, recommended, and default behavior for most Internet/SaaS traffic.

Illustration: Default Routing Flow

    sequenceDiagram
        participant User
        participant IngressPoP as London PoP
        participant PABackbone as PA Backbone
        participant EgressPoP as US-West PoP
        participant DestServer as Destination (US)

        User->>IngressPoP: Connect & Send Request (to US Server)
        IngressPoP->>IngressPoP: Apply Security Policy
        Note over IngressPoP, EgressPoP: PA internally determines optimal Egress PoP (US-West)
        IngressPoP->>PABackbone: Forward traffic (Destination: US)
        PABackbone->>EgressPoP: Route traffic across backbone
        EgressPoP->>EgressPoP: Prepare Egress (Select US-West Service IP)
        EgressPoP->>DestServer: Send Request (Source: US-West IP)
        DestServer-->>EgressPoP: Response
        EgressPoP-->>PABackbone: Route Response
        PABackbone-->>IngressPoP: Route Response
        IngressPoP-->>User: Deliver Response
    

2. Hot Potato Routing

Concept: Hand traffic off to the public internet as quickly as possible, egressing from the same region the user entered.

Traffic Flow & Behavior:

1. User traffic enters the nearest Prisma Access PoP (Ingress PoP).
2. Security policies are applied.
3. Prisma Access hands the traffic off to the public internet from the Ingress PoP (or a nearby peering point within the same region), using a Service IP from the ingress region.
4. Traffic traverses the public internet from the ingress region to the final destination. The destination sees a source IP from the user's region.

Benefits:

• Simple Egress Logic: Egress region matches ingress region.
• Specific Geolocation Needs: Ensures traffic source IP matches the user's geographic region (though Default Routing often handles this well via appropriate egress PoP selection).

Drawbacks:

• Variable Performance: Relies on public internet performance (potential for higher latency/jitter).
• No Backbone Optimization: Misses performance benefits of the Prisma Access backbone.

When Used:

This is not the default and typically used only for specific requirements (e.g., legacy needs, strict source geo-IP matching) or troubleshooting. Generally less preferred.

Illustration: Hot Potato Routing Flow

    sequenceDiagram
        participant User
        participant IngressPoP as London PoP (Ingress/Egress)
        participant PublicInternet as Public Internet
        participant DestServer as Destination (US)

        User->>IngressPoP: Connect & Send Request (to US Server)
        IngressPoP->>IngressPoP: Apply Security Policy
        IngressPoP->>IngressPoP: Prepare Egress (Select London Service IP)
        IngressPoP->>PublicInternet: Send Request (Source: London IP)
        PublicInternet->>DestServer: Route via Public Internet
        DestServer-->>PublicInternet: Response
        PublicInternet-->>IngressPoP: Route Response
        IngressPoP-->>User: Deliver Response
    

4. BGP Considerations (Peering with Prisma Access)

When using BGP (e.g., over Service Connections), understanding advertisements and communities is important.

• Prisma Access ASN: Can peer using the customer's public ASN or the **default private ASN 65534**.
• Advertised Prefixes (To Customer): As explained above, PA advertises only necessary prefixes (Service IPs, Compute IPs, optional default) due to outbound filtering.

BGP Community Exchange:

Communities ( ASN:Value tags) provide metadata about BGP routes.

• Communities Sent *by* Prisma Access (to Customer):
  • Purpose: Informational tags identifying the Location/Region (e.g., 65534:RegionID ) and Prefix Type (e.g., 65534:TypeID ) of the *specific* routes PA *does* advertise to you. (Note: The exact community format/ASN part might vary, always check received routes).
  • How to Find: Inspect received BGP routes on your router or consult official Palo Alto Networks documentation.
  • Role in Hot/Cold Routing: They help identify the origin of the PA Service IPs you learn about and allow you to infer routing behavior.
• Attributes/Communities Sent *by* Customer (to Prisma Access):
  • Purpose: To influence which Service Connection Prisma Access prefers for traffic destined back to your network when multiple Service Connections exist.
  • Primary Method (Recommended): Use AS Path Prepending . Advertise your internal routes with a longer AS_PATH (add your ASN multiple times) over the less-preferred Service Connection. Prisma Access prefers shorter paths.
  • Secondary Method (Communities - Requires Doc Verification): Attach specific community values defined by Palo Alto Networks to signal preference. You MUST consult official PA documentation for the exact supported communities for this purpose.
  • Other Methods: MED might also be used, depending on PA's configuration.

Illustration: Influencing Inbound Path via AS Path Prepending

    sequenceDiagram
        participant CustRouterSC1 as Customer Router (SC1 - Preferred)
        participant CustRouterSC2 as Customer Router (SC2 - Backup)
        participant PrismaAccess as Prisma Access BGP Process (ASN 65534 or Public)

        CustRouterSC1->>PrismaAccess: Advertise 10.1.0.0/16 (AS_PATH: 65001)
        CustRouterSC2->>PrismaAccess: Advertise 10.1.0.0/16 (AS_PATH: 65001 65001 65001)
        Note right of PrismaAccess: Customer (ASN 65001) prepends ASN on SC2 advertisement
        PrismaAccess->>PrismaAccess: Compare routes for 10.1.0.0/16
        Note over PrismaAccess: Prefers shorter AS_PATH (SC1's route)
        PrismaAccess->>PrismaAccess: Install route via SC1 into routing table
        PrismaAccess->>CustRouterSC1: Send traffic destined for 10.1.0.0/16 via SC1
     

5. Summary Comparison

6. Conclusion

Default (Cold Potato) Routing is the standard and preferred method for Prisma Access internet/SaaS traffic, leveraging sophisticated internal routing intelligence and the optimized Palo Alto Networks global backbone for performance. Hot Potato routing serves specific use cases where immediate egress from the ingress region is paramount, potentially sacrificing performance. Understanding BGP interactions, especially PA's route filtering, use of **ASN 65534** (private option), and how customers can use AS Path Prepending for return traffic engineering, is key for managing connectivity over redundant Service Connections.