This is risky of course as you lose access so you don't really know what is happening and if something fails it might be difficult for you to understand what is going on besides looking at various. Everything is running directly between the management server and the gateway using cdt so unless something happens during the process causing it to fail it will transfer the cpuse package or blink package of your choosing to the gateway, it will do the upgrade, it will automatically switch the gateway object in the management database to the new version and it will automatically push policy. But this is simply using central deployment tool so as soon as you have initiated the process it doesn't matter if you lose access to Smart Console or not. You will obviously lose track of what is going on you will lose access to Smart Console when the gateway is upgrading. Just right-click the gateway -> actions -> version upgrade and do it through the wizard in Smart Console. If you are upgrading to R81 or R81.10 you can utilise the version upgrade feature directly in Smart Console. Mgmt_cli install-policy policy-package "NAME-OF-THE-POLICY-PACKAGE" access true threat-prevention true If you already changed the gateway object so it has the correct version using SmartConsole beforehand all you have to do is to push policy using mgmt_cli which is quite simple: Then you utilise ssh from the gateway to reach the management and you can utilise mgmt_cli to push policy from the management to the upgraded gateway. The gateway should be booting with the initial policy after the upgrade so you are still able to reach it using SSH. Then you simply connect to the gateway using SSH. Also, make sure that you can reach the management server using SSH from the gateway. Make sure that you have a policy on the gateway that ensures that you can reach the gateway using SSH throughout the entire process.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |