In a Prisma SD-WAN deployment, the routing of traffic between branches and Data Centers (DCs) relies on the proper synchronization between the AppFabric (the overlay) and the local routing protocols (the underlay/LAN side). In this scenario, the branch can successfully reach DC1, indicating the branch ION is correctly participating in the fabric. However, traffic to DC2 (10.2.2.22) is failing.

The DC2 site has the site prefix 10.2.2.0/23 configured. In Prisma SD-WAN, defining a site prefix informs the Controller that this specific subnet "belongs" to that site, causing the Controller to advertise reachability for this prefix to all other ION devices in the fabric. Consequently, when the branch ION (192.168.1.123) attempts to reach 10.2.2.22, it correctly identifies DC2 as the destination and encapsulates the traffic toward the DC2 ION.

The bottleneck occurs once the packet arrives at the DC2 ION. While the ION is advertising the branch subnet (192.168.1.0/24) to the DC Core (ensuring the return path), the ION itself must know how to forward the incoming traffic from the branch to the internal DC network. If the DC2 ION does not have a specific route in its local routing table for the 10.2.2.0/23 subnet pointing to the DC Core's internal interface, the packet will be dropped.

According to Palo Alto Networks best practices for Data Center ION deployment, a static default route (0.0.0.0/0) should be configured on the ION device pointing toward the DC Core’s next-hop IP address. This ensures that any traffic received from the AppFabric destined for internal DC resources—which are not directly connected to the ION—is successfully handed off to the core switching fabric for final delivery. Adding this default route (Option A) resolves the reachability issue by providing the "last-hop" routing instruction within the DC.