On this page
Two official answers to one question
Palo Alto's Active/Active documentation offers two redundancy models as separate use cases. Floating IP addresses: both firewalls share virtual IPs, hosts point at them as gateways, device priorities decide ownership, and the address (with its virtual MAC) moves when a box or link fails. Route-based redundancy: no virtual IPs at all, each firewall keeps its own addresses and a routing protocol spreads and fails over traffic instead.
Reading them side by side invites the wrong question: which one is my pair? The better question is smaller: on this side of the firewall, does the neighbor speak BGP?
The neighbor decides
My pair runs both use cases simultaneously, and each side picked itself. Southbound, the firewalls face N9K leaves that are full BGP routers: route-based is strictly better there, because eBGP plus ECMP gives both boxes traffic all the time, failover is a route withdrawal, and there's no virtual address to babysit. That design (and its 3-second hold timer) is the first post in this series.
Northbound is a different world: an ordinary LAN full of hosts that only ARP, plus services published to clients that expect one stable address. You can't tell a laptop to run BGP. So that side uses exactly what the floating-IP use case describes: virtual addresses owned by device priority, answered with a virtual MAC, failing over on link-down. Here are both models live on the same pair:
What each model costs
The floating side carries the classic burdens: the address must be genuinely yours (a story for another day), failover depends on the LAN honoring a gratuitous ARP, and there's a sharp little gotcha: a floating address won't answer ping until you attach an interface management profile, so your monitoring can insist the gateway is down while traffic flows through it happily. The routed side trades all of that for BGP operational maturity: timers, session care, and knowing that config-sync won't manage any of it for you.
NAT rides these models differently than it would in Active/Passive, and the split is worth thirty seconds. In A/P the single active box owns both NAT directions: one egress identity outbound, and the published DNAT addresses simply follow activeness. In A/A the two directions part ways: destination NAT binds to both devices and hangs off the floating VIPs above (either box rewrites inbound for new sessions, stateless), while source NAT must be per-device because two dataplanes can't share one port pool, so outbound traffic leaves with two identities. The config-sync post shows the exact rules.
The nugget: floating IPs and route-based redundancy aren't competing philosophies, they're per-interface answers to "what can my neighbor do?" BGP speakers get routes. Everyone else gets a floating address. One Active/Active pair happily serves both worlds at once, which is precisely why the docs ship both use cases.
