PANOS 4.1 vs 5.0

[Krzysztof]

Which version PANOS is better 4.1 or 5.0

I have installed 4.1.8 on PA-500, should i upgrade to 5.0.2?

[MemphisBrothers]

Definitely not!  There is a bug in 5.02.  I had to roll mine back.  The bug caused the device CPU to hit 100% after a day or two and the only fix is restarting the management console.  The after effect there caused me to restart my device.  I am told by support that 5.03 has a fix for all that.

[ericgearhart]

If you enjoy the fast paced world of Quality Assurance then 5.0.2 is for you!

Otherwise stick with the 4.1 series until 5.0 stables off.

Just my two cents.

[MemphisBrothers]

Second that

[BobW]

It is my understanding that 5.0.3 should be out this week (first week of March).

Bob

[HITSSEC]

Unless you really need some of the new features, wait for 5.0.3  We have gone through the experience of upgrading to fix an issue just to inhrerit new issues with the current release until it settles down (usually .3 release or greater). A lot will depend on your pain threshold versus the benefits you will get right away with the new release.

Phil

[MemphisBrothers]

They tell me at least by the 3rd week of March. 

[mikand]

Perhaps the quality assurance people finally had to do their work properly? 😉

[BCH]

As far as I can tell, if you do not need any of the new features from 5.0, stick to 4.1.10-11 for the time being.

However 5.0.2 works quite well in our lab since the HF (4020 platform) 

[ericgearhart]

mikand - I know you're joking but that might not be fair... PA might simply not have enough QA folks to keep up with new releases and bugs. It might not be specifically "lazy/incompetent QA," it might be just that PA needs to throw more money at QA because QA is swamped with too much work

[mikand]

I disagree, looking at what kind of bugs actually passed the QA department of PA recently even you should start to wonder wtf is going on there (at the QA department)?

If the QA department have too much to do then there is another reason for why _NOT_ letting bogus software pass and hit the production lines.

For example the appid cache pollution bug is something I could appologize the QA department for not spotting (however it would be far better if they spotted this instead of the Checkpoint marketing department who then went ranting about it during the xmas holidays) - while the QoS bug in 5.0.0 and 5.0.1 is a good example that the QA process is failing big time. First that the QoS bug wasnt spotted (I mean its there in front of your face - its not some obscure "do these 500 odd stuff to your configuration before the bug shows up", and then when the bug was said to be fixed it took just minutes to find out that it actually wasnt. Which at least for me raises some questions on what did the QA department actually test regarding this QoS bug?

And of course, there can be other malfunctions within PA so perhaps I shouldnt blame on the QA department team too much but rather the QA process within PA (because if we take the QoS example perhaps the QA team wasnt involved at all - then there need to be a change within PA so bugs such as this (and specially when its claimed to be fixed) doesnt hit the production lines).

From my experience the difference between a good and a bad vendor is how problems are dealt with when shit hits the fan.

Of course there will be bugs but acting on a market where PA gear isnt exactly cheap stuff and there are competitors that will happily be ranting about things as soon as they get a chance (no matter if the ranting is true or false) then having a high quality QA process would be like a "company firewall" of bringing a good product to their (PA's) customers.