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.
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).
Thank you for the link to that document. That is interesting information that I haven't seen publicly available before. It seems in some cases the VM-700 is able to achieve over 10G of throughput. Why then doesn't PAN advertise or officially support this? We're running into educational institutions with 10G requirements. Fortinet does advertise a solution, although with twice the required vm-700 vcpus (32 vs 16). On paper, this put us at an immediate disadvantage.
We operate our own private cloud and we substantially tune for throughput whenever possible. So my question is less concerned with public cloud and I understand the issues there.
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.
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!