When installation is performed from the FortiManager, what is the recovery logic used between FortiManager and FortiGate for an FGFM tunnel?

Question

Options

• AAfter 15 minutes, FortiGate will unset all CLI commands that were part of the installation that caused the tunnel to go down.
• BFortiManager will revert and install a previous configuration revision on the managed FortiGate.
• CFortiGate will reject the CLI commands that will cause the tunnel to go down.
• DFortiManager will not push the CLI commands as a part of the installation that will cause the tunnel to go down.

• A
  80% (12)
• C
  7% (1)
• D
  13% (2)

Explanation

Explanation/Reference: The point of this question is "recovery logic". The only real issue of concern is whether the FGFM tunnel goes down because of the config pushed from FM to FG. If the tunnel goes down because of this pushed change, FM cannot do anything about it....because the tunnel is now down. The only way to have recovery logic when change was pushed from FM to FG, is to provide FG with a mechanism to determine if the changes it received caused the tunnel to go down. Therefore, the answer has to involve what the FG will do. FM's role is simply to provide FG with both SET operations for the change and UNSET options to roll back. Roll back occurs after 15min. FG will test tunnel condition and if it is down it will issue the UNSET cmd on those changes that it received. If this still does not resolve the tunnel down issue, the FG will reboot. Changes at this point are held in running (volitle) memory and will be lost (and therefore reverted) when FG reboots.

No community discussion yet for this question.