PA PLACEMENT

[simsim]

Hi, 

In internet edge ASA is running as Active /standby  . I would like to place PA as Active /Active in vwire mode behind   ASA 

What are the pros and cons 

Thanks

[reaper]

why not active/passive? 

active-active  makes your configuration slightly more difficult as you need to account for session ownership and adding a HA3 link that's large enough to support session packets if the ASA fails over (existing sessions will be bounced back and forth between the secondary PA and the primary who 'owns' the active sessions and needs to keep inspecting all packets for a flow)

other than that, unless your setup is more complex than a simple A/P north-south, there shouldn't be too many pitfalls

[EduardoNavarro]

I faced issues with the topology you mentioned.

ASA Active/Passive with Palo connected in Vwire in Active/Active behind the inside of the ASA.

ASA(inside A/P) - PA(vwire A/A) - Core

During normal operation traffic was working fine, the issue started when there was a failover on the ASAs.

• ASA during failover doesn't shutdown its interfaces (links stay up)
• In Palo there is no Failover triggered after an ASA failover (unless a direct link goes down) . 

When the ASA failover the VIP (ip) moves to the new ASA active (former passive) connected to the secondary PA, this trigger a gratious arp that traverse the PA secondary vwire and goes to the secondary core switch, forcing the traffic to the vip flow through the secondary pa to the new active ASA.

The challenge we saw is that there were many packet loss and those were caused because core was still sending packets through the Active Primary Palo that connects to the new standby ASA. those packets are drop by the ASA.

Why the core was sending packets through the link to the wrong ASA? What we saw is that Active-Primary Palo was closing sessions (valid sessions resets, close, threats, url blocks) and those resets generated by the palo contained the original destination and spof mac of the ASA vip. those packets triggered the learning on the core of the vip mac address of the Asa through the wrong uplink. and that behavior continued without any self relieve, until we forced a shutdown of the active-primary Palo or manually swap the role.

I was not able to get a proper response from tac on the issue, however we were able to replicate the issue multiple times,  Palo seems to be doing what has to do, the main response from tac is that this is not documented a valid design.  I tried playing with HA settings on the Palo, not able to resolve the issue,  if someone figure out the root cause or a solution I will like to hear it.