About EduardoNavarro

Did you were able to deploy Palo VM inside AVS?   Did you used ESX or NSX-T Service insertion mode?     I have tried NSX-T Service insertion mode on AVS we were not able.  Connection to NSX manager was ok, however when trying to deploy  the service, it was asking for the attachment point and none was available, it seems tier0 was not an option as its on active/active and even creating a tier1 it didn't allowed us to select it as an attachment point,  so not sure if I'm doing something wrong or if this is a limitation of NSX-T on AVS.     Any suggestion or feedback is welcome.    thanks ... View more

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.   ... View more