2050 only handles 1/4 of its advertised throughput

Reply
Highlighted
L4 Transporter

2050 only handles 1/4 of its advertised throughput

Has anyone here tried to benchmark there Palo Alto Firewalls? We are using Breaking Point(same company that Palo Alto uses)to test our Lab 2050's.  We have come to the conclusion that the PA 2050 starts dropping packets at about 250Mbps(with about 5-600 new sessions per second).  This is with Threat Prevention disabled.  The 2050 is spec'd out to be able to handle 1Gbps of Firewall traffic with Threat Prevention disabled.  The Breaking Point is acting as the Client and the Server.  We put the rules that allow the Breaking Point traffic at the very top.  The Breaking Point Client is doing a simple HTTP GET request, and the Breaking Point Server responds with a 44k text file.

Running this command...

"show counter global filter severity warn delta yes"

...these counters normally have the highest hits...

-Software packet buffer allocation error

-packets dropped because of failure in tcp reassembly

-out-of-window packets dropped

Tags (1)
Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

This test was conducted using some pretty idealized conditions as well (as idealized as we can come up with)... HTTP GETs between a client and server, with only the PA 2050 acting as the router/firewall between the two subnets. Also we made sure App-ID caching was enabled, just in case turning that off had a performance impact.

Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

Hi,

There is also a resource limitation on the packets per second (~20000 - 25000) that the PA-2000 series hardware can handle, in my experience. 44k is a small packet, resulting in a fair amount of packets per second. What is the total throughput is you increase the packet size to 1500k?

Ben

Highlighted
L6 Presenter

Re: 2050 only handles 1/4 of its advertised throughput

44k is 44000 bytes (or 45056 bytes depending on if you count k as 1000 or 1024)... meaning contains several 1500 bytes packets already if thats what you mean - of course unless the test performed forced to use smaller packets?

Jambulo: Could you paste the config used so the community forum can take a peak in case there is something in there which (for performande reasons) isnt properly setup?

Also verify so you dont have bad interfaces or bad cabling which could end up with resends which of course will get you lower values.

The 2050 is speced for:

(1) Gbps firewall throughput (App-ID enabled1)

500 Mbps threat prevention throughput

300 Mbps IPSec VPN throughput

250,000 max sessions

15,000 new sessions per second

With the note of:

(1) All performance and capacities are measured under ideal testing conditions using PAN-OS 5.0.

where it previously was written that the test (to get the performancenumbers) was using a specific size of http-transmissions (if I recall it correctly).

Looking at other performance tests you could try a payload of 1megabyte to see if you can reach topspeed, however number of transactions per second will drop compared to lets say when using 64k payload (which will have far more transactions per second but only slighly lower throughput counted in Mbit/s).

To max out transactions per second you can go down to 4k payload which will drop the Mbit/s but show you peak in transactions per second (or even down to 512 bytes I think).

Another thing to test is to enable jumboframes (both on the PA device and on the loadgenerator) and see how that will affect transactions per second and throughput for a given payloadsize.

Yet another thing to test is to use a single download but lets say 1gigabyte of payloadsize and see which throughput you get with that.

So to max out throughput numbers a test something like this could be performed:

1) Use a single security rule that is setup like:

srczone: any

dstzone: any

srcip: any

dstip: any

appid: any

service: any

threat: none selected (like no IPS, AV, FILE, URL etc).

options: none select (like no logging etc).

2) Verify that both ends are up with 1Gbit/s full duplex (or 10Gbit/s if you use such interfaces) - connect directly to the PA device (like no switch or such in between).

3) Enable jumboframes on both the PA device and the loadgenerator.

4) Perform the test with a single transaction but with 1Gbyte (or more) as payloadsize.

If the above doesnt get you close or above the numbers presented in the datasheet I would contact support to verify that there is nothing wrong with the particular PA unit (like RMA or such).

If I recall it correctly NSS Labs got optimal performance numbers of 115% above the one stated in the datasheet - these numbers will of course vary or for that matter go down if you have smaller payloadsize etc.

Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

Thanks for the reply mikand... yes we were definitely trying to recreate something near the NSS Labs results. We went into this hoping that we'd be pleasantly surprised at the 2050's performance numbers given NSS Labs' numbers.

Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

mikand wrote:

So to max out throughput numbers a test something like this could be performed:

1) Use a single security rule that is setup like:

srczone: any

dstzone: any

srcip: any

dstip: any

appid: any

service: any

threat: none selected (like no IPS, AV, FILE, URL etc).

options: none select (like no logging etc).

We created something similar to this... I built an "outside" zone and an "inside" zone, with them bound to one interface each. I had one rule at the top of the rulebase for the test, testing from outside -> inside for application web-browsing. Also the Service column was set to "service-http."

We tried with logging on and logging off as I recall... we still weren't able to get decent numbers out of the PA2050.

Also we checked the switch interfaces throughout this test (show int gig1/1, show int gig1/2, etc) and they were clean throughout the testing.

Highlighted
Not applicable

Re: 2050 only handles 1/4 of its advertised throughput

I did some simple benchmarking when doing VPN testing and got better speeds than that over IPSEC.

What release are you running? I have a few 2050s in our lab so I can have a go at it some time this week to see if I can reproduce your problem.

As I understand you have two zones and an allow all rule on service http with one interface assigned per zone?

What tool did you use for testing?

Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

nisse wrote:

What release are you running? I have a few 2050s in our lab so I can have a go at it some time this week to see if I can reproduce your problem.

We have two lab PA2050s... we tested with both 4.1.11 and 5.0.2 as I recall

nisse wrote:

As I understand you have two zones and an allow all rule on service http with one interface assigned per zone?

That is correct... we used the "web-browsing" App-ID too.

nisse wrote:

What tool did you use for testing?

We used IXIA's BreakingPoint to test. The BreakingPoint device was acting as the client and the server (two separate interfaces). We actually had a BreakingPoint engineer here during the tests as well.

FYI, I would honestly love to be proven wrong! I like our PA devices, and I'm trying to push for using them more in our network designs.

Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

An update on this thread... PA is sending us an eval 5000 series box and an eval 500 series box, and they promise they're going to hook up us with their BreakingPoint test profile so we can import their settings and hopefully recreate their own findings.

I'll add to this thread when we get the boxes, get them racked, apply the BreakingPoint test case, etc.

Highlighted
L4 Transporter

Re: 2050 only handles 1/4 of its advertised throughput

As a followup to this, we're still waiting on PA to provide us with their in-house Breaking Point test profile.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!