Dear PA re Active Active

[Alex_Samad]

Hi

Lots of people say stay away I tried.

BUT PALOALTO PLEASE DON'T ADVERTISE THIS AS A WORLING PRODUCT CAUSE IT AIN'T.

to any one thinking of A/A please test and test again will fail over.  Pull one of the HA1 or HA2 cable ..  the system can't handle it.

It should be marked up as BETA 

[BPry]

@Alex_Samad,

There are very few instances where Palo Alto recommends Active/Active HA. Pulling either of the HA cables would result in any Floating IPs moving to both IPs, resulting in possibly multiple instances where two different active devices were broadcasting the same IPs. The same exact instances where you would run into issues with Active/Passive. 

You effectively purposely broke everything that would keep these devices working properly. Active/Active or Active/Passive pulling the HA cables would cause a tremendous amount of issues as you have both devices actively ARPing the same IPs and attempting to process traffic. 

I'm all for telling people that they should stay away from Active/Active unless they meet a situtation that actively calls for it; but that doesn't discredit the fact that you effectively did the one thing that would break any High-Availability setup, regardless of Active/Active or Active/Passive. 

If you believe that this testing means Active/Active should be marked as a beta product, go test the same exact thing with an Active/Passive setup. You'll find that this breaks any HA setup as you severed the very functionality that makes this entire setup function. 

[Alex_Samad]

Hi  BPry

Sorry, thats wrong ... let me expand.

Each HA port 1 2 & 3 - all had multiple links into the switch stack. pulling one of those shouldn't have caused a catastrophic fail.

I think you are either miss understanding or ? when you say 

"

You effectively purposely broke everything that would keep these devices working properly. Active/Active or Active/Passive pulling the HA cables would cause a tremendous amount of issues as you have both devices actively ARPing the same IPs and attempting to process traffic.

"

Plus i had it setup to fail over only if I had lost all connections.

If as you say my same test fails in A/P setup. I am going to be asking for my money back .... Note the SE and PA support said it should work.

But having said that, I have had support tell me my setup is correct and then told 2 weeks later its wrong ... sigh.

so again just in case there is / was some confusion.

For HA1 i used 2 cable to connect -  different switch - same stack

For HA2 i used 2 cable to connect - different switch - same stack

For HA3 i used 2 cable to connect (LACP) - different switch - same stack

If you are saying 

1) pulling one of those redundant cables is enough to bring the PA to its knees - them I am not impressed with the PA's

2) pulling one of those redundant cables caused a fail over - okay so what its supposed to handle that  - i could live with a small network interruption. 60-90 later I still had problems

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/high-availability/ha-concepts/ha-lin...

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/high-availability/set-up-activepassi...

These links to pa doco imply there are redundant links to allow it to function properly if one fails.

note after digginf around with my broken system, i found to fix it was to shutdown the 2nd link - the other link. which forced it to fail over completely

And as for recommending A/A - its sold a feature of its not ready - mark it as such - i presonally feel its still beta ish with all the issue i had with it

GP and VIP - fail 

seems like the new 4.1 GP has issue with A/A - my portal stopped working - moved to A/P start working without a flaw

Other wierd and funky stuff.

I'm all for trying new stuff and I had a reason for doing it. But .... so many corner cases ...

Each to their own milage, but I rather take offence at 

"

You effectively purposely broke everything that would keep these devices working properly.

"

[BPry]

@Alex_Samad

So I want to point out that your first post never mentions that you were using multiple connections for HA1 and HA2, simply that you removed HA1 or HA2 and things broke, as one would fully expect. It's additional details such as "hey, I was using redundant links" that make all the difference here. As for my first response I stand by it, without the additional detail this would be expected behaviour that you instegated. 

So now we can start working on the actual issue here, and that's removing one of your HA1 or HA2 links caused issues when you actively had redundant links built in. Again, totally seperate situation. When configured correctly pulling one of the HA1 or HA2 links, when you have the backup links configured, shouldn't have caused you any issues. 

Without seeing how you have this configured I'm going to 100% say you have something misconfigured, as I have a handful of A/A pairs with this same connection and don't have any issue pulling one of the HA1 or HA2 links and having everything continue to function. 

As for encountering configuration issues with A/A you're not wrong, A/A is actively advized against and only used in applications that actually call for it. Meaning that more issues are present on A/A then say A/P when the releases are available, you have to account for this and really test quite a bit more with this in mind.