About nanasin

Palo Alto does not advertise and support it because it does not benefit them. In this area, their main battleground is the public cloud where Prisma Access is running. So for products running in the public cloud (mainly AWS), it seems that they are updated with every new PAN-OS that comes out. Private clouds, in this case, Network Functions Virtualization (NFV), can achieve unified High Availability (HA) through live migration, scale up through physical enclosure replacement, expand physical enclosure to scale out. If we follow Moore's Law, the capacity of NFV doubles in 18 months simply by replacing the physical enclosure. In a virtualized product, capacity and performance can be determined by us, who can choose the physical enclosure, not the manufacturer. Conversely, if we are using an old physical enclosure, then of course it will not perform. Performance and capacity is our responsibility as users, not the manufacturer. Physical enclosures without an OS are cheap, but physical enclosures that work as products (i.e., traditional network devices) are very expensive. Once manufacturers officially support live migration, what used to require multiple physical enclosures for HA will be able to be one virtualized product. If the virtualized product is not a subscription license, these facts are a manufacturer's nightmare. For the above reasons, Palo Alto has little benefit in supporting performance and promoting performance in specific environments with respect to its products for the private cloud, even though there are risks. Maybe they want to stop selling and supporting some of their products per se (I think so, especially for the KVM). And the benefit of advertising the performance improvements of NFV-related products lies with the hardware vendors selling the physical enclosures and the manufacturers of the hypervisors. So you're looking at the wrong people for capacity and performance support. You should be looking to the hypervisor and hardware manufacturers.   ... View more

Isn't it the same VCN but can't communicate between different subnets? VCN Transit Routing is likely to be required for subnets that want to communicate with or through PA VMs. You can find it at https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/transitrouting.htm ... View more

What OIDs are you using in SNMP monitoring? If you are monitoring hrProcessorLoad, you will only see two objects, no matter what model of Palo Alto FW you are using. It corresponds to the utilization of the data plane and the management plane. Also, these values correspond to the values of the system resource wedge in the dashboard. You can find it at https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClaSCAS If you want to see the utilization per VCPU, you need a little trick. Please press "1" after running "show system resources follow" to toggle view to show separate states. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLZZCA4 I do not know the REST API that corresponds to this idea. Naturally, I don't know the corresponding SNMP objects either. Therefore, I don't believe there is an elegant means of continuous monitoring. In the VM-Series and PA-850, for example, the management plane and the data plane are not physically separated, and the data plane is run as a process called pan_task. The number of pan_task processes increases or decreases according to the capacity of the Palo Alto FW and is allocated to logical cores from CPU1 onwards using CPU affinity (a feature of the Linux kernel). I remember that the CPU utilization of the pan_task process, which can be checked with the above command, behaved a little differently depending on whether SR-IOV was enabled or not. ... View more

SR-IOV and DPDK can be enabled simultaneously. Slightly misleadingly, SR-IOV is assisted by the network card and DPDK is assisted by the CPU. https://en.wikipedia.org/wiki/Data_Plane_Development_Kit https://en.wikipedia.org/wiki/Single-root_input/output_virtualization Enabling SR-IOV bypasses the hypervisor that exists between the PAN-OS(VM-Series) and physical NICs. Enabling DPDK bypasses the PAN-OS (linux kernel) that resides between the NIC bypassed by SR-IOV and the pan_task (a process that represents the data plane). DPDK is effective for simple processes such as just moving data from east to west, raising the limit from around 20 Gbps to around 100 Gbps. I think DPDK probably won't be effective until Threat Prevention's throughput exceeds 30 Gbps, which is not very useful at the moment. In other words, I don't think it's very useful at this time (the unconfigured defaults should be the most secure). Where DPDK is useful is in eliminating most of the bottlenecks, even in configurations that connect via Open vSwitch (OVS). Here are Intel's test results https://builders.intel.com/docs/networkbuilders/demonstrating-data-plane-performance-improvements-using-enhanced-platform-awareness.pdf It should be possible to use OVS in AWS as well, but there should be little benefit to using it (although I did some research). Therefore, I think it's enough to just enable SR-IOV, and I think it's safer to not change the default. ... View more

Whatever hypervisor you are using, with proper CPU pinning (or CPU affinity) settings and SR-IOV settings, Threat Prevention can achieve 10 Gbps on modern high performance servers.   Check the Table 4, where Threat Prevention achieves 13552 Mbps. See https://eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-TestReport-PaloAlto-v1.0.pdf   However, most network engineers cannot properly tune the above settings, and they are impossible to tune in the public cloud. Also, since HTTPS traffic accounts for more than 80% of any enterprise traffic, Threat Prevention's 10 Gbps is rarely useful because SSL Decryption is the bottleneck.   Even in the Table 4 above, the throughput of SSL Decryption is only 24722 Mbps (about 18% of Threat Prevention).     ... View more