Differences

This shows you the differences between two versions of the page.

--- paloaltonetworks:vmseries:azure [2021/09/06 13:19] – bstafford
+++ paloaltonetworks:vmseries:azure [2022/12/02 11:54] (current) – bstafford
@@ Line 12: / Line 12: @@
 You can deploy Panorama on 4CPU/8GB RAM but it will be limited to Management Mode only. For Panorama mode, you need at least 8 CPU and 16 GB of RAM.
+In Azure for just managing 6 VM's, standard_D3_v2 should be sufficient if there is no logging happening. If you need Panorama in mixed mode, you must apply proper resource to the VM.
-Just managing 6 VM's, standard_D3_v2 should be sufficient if there is no logging happening. If you need Panorama in mixed mode, you must apply proper resource to the VM.
+HOWEVER, recent PAN-OS versions will complain every single time you log in to Panorama if you don't have 16 CPU and 32 GB of RAM. It will complain even if you have 8 CPU and 32 GB of RAM.
+Use ''D5_v2'' (or, as of Sep 2022, ''Standard_D16s_v3'' apparently) for the correct performance (16 CPU and 56 GB RAM). This will be ~£750 a month in Q4 2021. However Azure Reserved Instances is an Azure Accounting "thing" that can save end users month on machines that are permamently deployed.
+In June 2022, the reference archtiecture says to use Standard_D16s_v3.
+As of Sep 2022:
+  * D16_v3 is 16 CPU and 64 GB RAM and is about $675 per month to run (not including 'reserved instance')
+  * D5_v2 is 16CPU and 56 GB RAM and is about $1,025 per month to run (not including 'reserved instance')
 ===== Pay-As-You-Go =====
 As of 28th Feb 2018
@@ Line 56: / Line 65: @@
 ===== Load Balancer Health Probe =====
-The Azure LB health probe does not complete a 3 way handshake - just the SYN and the SYNACK. On tcp-80 this is identified as "incomplete". On tcp-22 this is identified as ssh. Palo Alto Networks suggest using tcp-22 as the CPU related issues seem to only occure when deploying in GCP.
+Azure Health Probes target the firewall interface IP.
+The Azure LB health probe does not complete a 3 way handshake - just the SYN and the SYNACK. On tcp-80 this is identified as "incomplete". On tcp-22 this is identified as ssh. Palo Alto Networks suggest using tcp-22 as the CPU related issues seem to only occur when deploying in GCP.
+===== Deployment Notes =====
+For public load balancers, enable "Floating IP". For load balancers, "Floating IP" is not technically needed. All it gives you is that the firewalls will see the public IP that the remote resource is connecting to instead of the load balancer applying a DNAT. However, this can be very useful. It also makes it easier to scale when adding in new public IPs.
+REMEMBER. When adding a secondary IP to the front end load balancer, you must enable "Floating IP" before setting the backend pool and ports.
-===== Deploymnet Notes =====
-For load balancers, "Floating IP" is not technically needed. All it gives you is that the firewalls will see the public IP that the remote resource is connecting to instead of the load balancer applying a DNAT. However, this can be very useful. It also makes it easier to scale when adding in new public IPs.
 Configure the firewall to update its domain based on the DHCP allocation.