Software Update Issue

[VSU_ITSEC]

Last month I upgraded to 6.0.4 with no issues.  I upgraded my primary, then upgraded the secondary five days later. Again, no problems.

When I upgraded to 6.0.5 h3 (this past weekend), the PA would not pass traffic. I returned to 6.0.4 and traffic restored. I then tried 6.0.5 and had the same problem - no traffic.

I followed the same procedures as I did with the upgrade to 6.0.4.

Any ideas?

Thanks as always.

//moe

[ssharma]

Hi Moe,

Do you have asymmetric flow in your environment.  There has been couple of changes in the way firewall handles Asymmetric traffic with 6.0.5-h3.

Before upgrading again, run following commands to ensure continuity:

set deviceconfig setting tcp asymmetric-path bypass

If you also have zone protection, run following commands as well :

set network profiles zone-protection-profile <profile-name> asymmetric-path [bypass | global]

Hope this helps. Thank you.

[panos]

interesting that you have the issue with 6.0.5 also

[ssharma]

Here is link to Release note:

https://downloads.paloaltonetworks.com/software/PAN-OS-6.0.5-h3-RN.pdf?__gda__=1413249439_2154724505...

And note mentioning changes in the behavior :

"

Note If you have asymmetric routes in your network, before upgrading to 6.0.5-h3, use

the following command to ensure session continuity:

set deviceconfig setting tcp asymmetric-path bypass

And, if you have attached a zone protection profile, you must also use the

following command:

set network profiles zone-protection-profile <profile-name> asymmetric-path

[bypass | global]. "

[VSU_ITSEC]

We are symetric right now.  Will be asymetric in a couple months. 

[ssharma]

In that case you will need to configure those commands prior to upgrade. That should work, if not then you can contact support for further troubleshooting. Thank you.

[VSU_ITSEC]

will the command disrupt traffic before the software is updated? What i'm asking is, can I do this now, and upgrade later?

[ssharma]

There should not be any disruption with the command, however I would suggest configuring these command just prior to upgrade. Everything should work as expected until 6.0.5. Above condition only applies if you are on 6.0.5-h3 or above and you have asymmetric traffic in your environment. Thank you.

[VSU_ITSEC]

What about for right now?  My traffic is symetric, yet I had no traffic.

[ssharma]

If you upgrade to 6.0.5-H3 and you did not have asymmetric traffic and it did not work, that would be something not expected. I would suggest opening a case before next upgrade attempt so that a resource can work with you to verify the issue. It would be hard to tell why traffic did not work. If you look at the monitor logs during the upgrade and see both side traffic was seen (Bytes Sent/Bytes received). I believe you did wait until Auto Commit was completed. Were you able to ping inside interface during the incident? Were you able to ping outside sourcing from one  of the inside interface. There can be many variables why it caused that, but 6.0.5-h3 alone would not be issues as we have seen successful upgrades as well. Hope this helps. Thank you.

[VSU_ITSEC]

I was pinging the management interface (didn't consider the inside int) and google.com while the firewall rebooted. The management came back up and i could log back into the device. the ping out to google didn't come back.  I have two firewalls in HA active-pasive mode. I was updating the primary. (the secondary's inside/outside interfaces are currently not connected to switch)

[ssharma]

Yes, management interface will respond. But after reboot, auto commit is happens on the device. During this time all dataplane ports would not respond or pass any traffic. Depending on the Hardware of the device and amount of configuration it might take time for auto commit to complete. "show jobs all"  shows progress for the auto commit. While updating, secondary will take over as active, and since interfaces are not connected to switch the traffic will be basically blackholed.

Next time during the upgrade monitor the auto-commit, and once it is done, make the primary (connected to switch) active device again and see if that resolves the issue. Thank you.