- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-01-2019 01:11 AM - edited 10-01-2019 01:26 AM
Hello,
We are about to work on a Paloalto cluster deployment, which will be sitting next to the internet (we will have two separate providers) and we need to make the decision whether we configure it as A/A or A/P.
I keep reading in quite some places (forums and so) that A/P is Paloalto preferred way. That is also my first option, but I would like to have some official documentation to support that decision. Does anyone know where I can find such documentation from Paloalto, where they discuss A/P against A/A?
(I have been able to find the technical documentation of each of the cases, as well as their requirements, but not a specific discussion detailing kind of pros and cons of each of them).
Thanks a lot in advance
Jorge
10-01-2019 02:33 AM
Not sure you will find any documented reasons but basically..
You don't gain much from A/A other than more throughput during normal running, but your not running N+1 so if one FW dies your under capacity. The added complexity also makes it far more difficult to implement successfully.
Hence a properly sized A/P N+1 is the recommended.
10-01-2019 06:34 AM
Are you utilizing any dynamic routing protocols with you service providers (and internally)? You might want to consider A/A. What you will learn is this can be very beneficial but will require a lot of setup on you part with a good working knowledge of BGP/OSPF/etc.
No dynamic routing protocols on either side? Stick with A/P.
10-01-2019 06:44 AM
@jorgebarba wrote:Hello,
We are about to work on a Paloalto cluster deployment, which will be sitting next to the internet (we will have two separate providers) and we need to make the decision whether we configure it as A/A or A/P
....
Thanks a lot in advance
Jorge
In our deployment we have 3 independent ISPs across 2 DCs and we run A/P. As others have stated an A/A deployment is primarily about throughput. If you become reliant upon that second firewall's throughput then when you upgrade or a failure occurs you're environment is now degraded in an A/P deployment you're at N+1 which makes for a much more stable environment.
10-01-2019 08:08 AM
Thanks all for the replies.
@jeremy.larsen, indeed we will be running BGP to the internet and (most likely) OSPF internally. But the point is that I do not really see those benefits anyway, in setting the cluster up as A/A. Or say it other way, I do not see any potential benefit that would pay off the rather important increase in complexity (not that it is an issue itself, but it also would complicate any troubleshooting when the time comes, for the NOC and so).
Again, thanks all for providing your inputs. That's kind of what I am looking for, to gather a list of pros and cons of each of the two options, to make the final decision.
Jorge
10-01-2019 01:56 PM
I've done both. A/A is definitely cool but requires a lot of planning and a deep understanding of what you are doing. If you want BGP to handle the failover for inbound services (ie: website, etc) then A/A is the way to go. Or you can drop HA and use Load Balancers to handle your firewalls and all the routing decisions. If you have something like an F5 handing failover using DNS and no IPs are getting moved between locations, then use good 'ole A/P and call it a day.
- Just my 2 cents
10-02-2019 11:55 AM
Hello,
The big thing to consider is asymentric routing. If you have the need then A/A, if not then A/P.
Regards,
10-03-2019 06:23 AM
Agreed,
Sorry I didn't state this in my previous post.
10-09-2019 12:10 AM
Thanks all again for your input.
In fact, I think I still opt more for the A/P solution but we will explore the two options in our particular environment and will decide.
Thanks!
Jorge
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!