Link Search Menu Expand Document
calendar_month 07-Mar-24

Reference Architectures

The orchestrated integration of SD-Branch and Microbranch with Prisma Access allows for a wide variety of scenarios. This section describes the most common ones, which have been validated by the HPE Aruba Networking Engineering and QA teams.

Table of contents

Microbranch Integration with Prisma Access

The Microbranch integration with Prisma Access is the simplest of all. In this case, Cloud Connect will build tunnels to the nearest SPN (unless overridden as part of the configuration), and Internet-bound traffic will be forwarded through said SPNs using PBR policies applied to the user roles. For Microbranch deployments with dual uplink interfaces, tunnel definitions will be created for both uplinks, but only those tunnels sourced from the active interfaces will come up.

Internet-bound traffic from Microbranch forwarded through Prisma Access

Gateway Integrations with Prisma Access

Branch Gateway forwarding Internet traffic via Prisma Access

Just as in the case of Microbranch, Branch Gateways are often integrated with Prisma Access with the sole intention of forwarding traffic destined to the Internet. For simplicity’s sake, Cloud Connect will always establish the BGP peering between the Gateways and Prisma Access, but there won’t be a need for any prefixes to be learned, as the traffic should be forwarded through Prisma Access using PBR policies.

Internet-bound traffic from Branch Gateways forwarded through Prisma Access

When redundancy is required inside the branch, Branch Gateways can share WAN uplinks with their HA pairs. This establishes a virtual uplink through the LAN to share such WAN circuits. The result, as shown in the image below, is that each Branch Gateway would have “physical” uplinks as well as “virtual” uplinks.

BGP over IPsec

In a scenario like this, each Branch Gateway establishes tunnels to Prisma Access through all public uplink interfaces (those labeled as INET or LTE), regardless of whether they’re physical or virtual. Cloud Connect would define both Branch Gateways as separate “Remote Networks”, each one with separate IKE/IPsec Gateways, VPN Credentials, etc.

Headend Gateway forwarding Internet traffic through Prisma Access

Branch traffic is sometimes aggregated at a local hub and then routed to the Internet or to other corporate resources. This case is mostly common when using private WAN in the branch locations. In such scenarios, Headend Gateways (VPNCs) can set up tunnels to the nearest SPN to have branch traffic go through additional security inspection.

Tunnels to Prisma Access via Regional DCs

East-West connectivity through Prisma Access

Aruba generally recommends leveraging the SD-WAN overlay for site-to-site communications; it allows for simpler deployments that are more cost-effective and provide better performance (the SD-WAN overlay features like Forward Error Correction, faster DPS, etc.). East-West communications can also be done through Prisma Access, leveraging SSE as the transport between sites. To facilitate that, Cloud Connect automates the configuration of key routing features from Prisma Access and the SD-Branch gateways.

A network where all East-West communications happen between Prisma Access would look like the following:

East-West Routing

Note: Routing site-to-site traffic via Prisma Access may require additional license entitlement. For more detailed information on Prisma Access, its capabilities as well as licensing please check directly with a Palo Alto Networks representative or a certified partner.

Ensuring Traffic Symmetry in Branch HA locations

When the integration with Prisma Access is exclusively being used to forward Internet-bound traffic through Prisma Access, SPNs will always return traffic through the tunnel where it was initiated, which means that traffic symmetry is guaranteed regardless of the routing configurations. However, when Prisma Access is also being used for downstream connectivity into the branch locations, it’s important to ensure the preferred downstream path is the one through the primary gateway.

To do so, the route redistribution done in the secondary gateway should prepend the Autonomous System (AS) to make routes advertised by the secondary gateway less attractive than those advertised by the primary gateway.

AS Path Prepending for Branch HA

Note: This additional step is only necessary when there’s a desire to route site-to-site Traffic via Prisma Access.

Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.