topic Re: maintenance mode in General Topics

maintenance mode

jdprovine — Tue, 30 Jan 2018 20:59:34 GMT

Does anyone know what maintenance mode is and how to put the firewall in that mode?

Re: maintenance mode

OtakarKlier — Tue, 30 Jan 2018 22:01:54 GMT

Hello,

Under general functionality, its not used/needed when they are already deployed, if you are referring to the following.

https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Enter-Maintenance-Mode-on-the-Palo-Alto-Networks-Firewall/ta-p/55082

Regards,

Re: maintenance mode

BPry — Tue, 30 Jan 2018 22:15:14 GMT

@jdprovine,

There is very little reason to boot a firewall into maintenance mode. Some examples would be performing a factory reset, setting FIPS, CCEAL4, performing a disk check, disk image changes, content rollbacks, and stuff like that. I would say easily that 95% if not more of Palo Alto customers should never have to boot into maintenance mode.

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 13:19:29 GMT

@BPry @reaper @OtakarKlier

I have a ticket open because my upgrade to 7.1.14 from 7.1.13 failed and according to the system logs and TAC it is due to a autocommit failure. It was their recommendation to go into maintenance mode and attempt the upgrade again. Since I can't really understand most of what the TAC tech says or writes I am confused.

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 13:20:46 GMT

@OtakarKlier

Yeah I don't see what good it would do other than a factory reset , which is not what I intend on doing unless there is not other way

Re: maintenance mode

kiwi — Wed, 31 Jan 2018 13:39:04 GMT

@jdprovine,

If everything fails ... before going into maint mode and performing a factory reset I would suggest trying to revert back to the previous version using the 'debug swm revert' CLI.

Good luck !

-Kiwi.

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 13:45:16 GMT

@kiwi

I was able to revert back to the previous version through the GUI with no issue and maintenance mode was the recommendation of TAC, not sure why. But I was thinking about attempting the upgrade again in hopes of collecting additional information. TAC said when I reverted back to the pervious version it wiped out the logs, but for some reason it did do anything to the system logs. So this command debug swm revert' CLI. besides reverting back to the previous version does it get me additional information? FYI I have two PA's in and HA pair. The PA I am trying to upgrade is the passive firewall

Re: maintenance mode

BPry — Wed, 31 Jan 2018 14:05:35 GMT

@jdprovine,

Not sure why TAC would tell you to update through maintenance mode, that seems rather odd to me as long as you were able to revert to a working configuration. In past experiance autocommit issues have always been solved by a rollback and then repeating the process, usually I simply restart the box in question before I attempt the upgrade again just so I know it's got a 'clean' baseline. I've never heard of anyone recommending an upgrade through maintenance mode for anything.

To be clear, I think what TAC is telling you to do would likely work perfectly fine. I just don't think it's actually necessary and you can get yourself in a little bit of a pickle in maintenance mode if you aren't being careful.

debug swm anything gives you slightly more information than would previously be available. The revert command however will revert the configuration to the last successfully loaded version, I believe that it enables a little bit of extra debugging on the software manager during the process. You may want to run the command 'debug swm history' and verify exactly what the failure reason was. If it was trully just an autocommit issue I would recommend simply attempting the upgrade again after restarting the box; generally that's cleared things up for me in the past.

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 14:12:08 GMT

@BPry

this was the process I followed

1. Downloaded and upgraded the passive PA to 7.1.13 to 7.1.14

2. Rebooted, when it came back up the status light was yellow the interfaces were all greyed out and it kept saying autocommit failed.

3.Gave it 15 or 20 minutes to see if it would come back on its own

4. Rebooted the firewall

5. When it came back up the status light was yellow the interfaces were all greyed out and it kept saying autocommit failed.

6. Reinstalled 7.1.13 and rebooted. Everything came back fine

7. Upgraded the passive PA to 7.1.13 to 7.1.14

8. Rebooted, when it came back up the status light was yellow the interfaces were all greyed out and it kept saying

autocommit failed

9. Reinstalled 7.1.13 and rebooted. Everything came back fine

10. Tried to collect all the information and logs to open a ticket with TAC

Re: maintenance mode

BPry — Wed, 31 Jan 2018 14:16:15 GMT

@jdprovine,

On your box now what's the output of 'show chassis-ready'?

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 14:18:30 GMT

@BPry

Currently while on version 7.1.13 the out put of

show chasis-ready is yes

I don't know what it would be on the upgraded version of 7.1.14 until I do the upgrade again

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 14:25:39 GMT

@BPry @kiwi

I also ran this (this command is just for the following out put its not constantly collecting additional logs is it? I don't have to turn on debug like I would a switch do I )

debug swm status

sysroot0 REVERTABLE 7.1.14
sysroot1 RUNNING-ACTIVE 7.1.13
maint READY 7.1.13

Re: maintenance mode

BPry — Wed, 31 Jan 2018 14:29:15 GMT

@jdprovine,

It would have been a no after the 7.1.14 upgrade if the auto-commit process is failing. Essentially if that fails the dataplane and all of your interfaces will show down.

So I would redo the upgrade, but right after you restart for the upgrade perform the following. (This needs to be done quickly before the auto-commit process starts, I would advize doing it through the console port.)

debug management-server set commit all

debug management-server set cfg all

debug management-server set content all

debug management-server on debug

debug device-server set all

debug device-server on debug

Logs will be generated in ms.log and devsrv.log

Once the auto-commit fails or finishes then run the following

debug management-server on info

debug device-server on info

That should provide TAC with all the info they need to see exactly what is going on with autocommit and why it's failing.

Re: maintenance mode

BPry — Wed, 31 Jan 2018 14:31:18 GMT

@jdprovine,

The swm debug commands that were given would not turn on additional logging, so you don't have to turn them off or 'no' them out if that's what you mean.

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 14:31:33 GMT

@BPry

Great information I wonder why TAC didn't make any or these suggestion to me. The only suggestions they made were to reboot it and put it in maintenance mode

Re: maintenance mode

jdprovine — Wed, 31 Jan 2018 14:32:24 GMT

@BPry

Exactly what i meant, I don't want to fill up my log partitions with extra logs