<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic MVC mode is off in Hyperscale Firewall (Maestro)</title>
    <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/MVC-mode-is-off/m-p/280564#M4348</link>
    <description>&lt;P&gt;Hi All. This is probably just a general appeal for comments / feedback. I don't actually have a fault or problem condition on the Maestro cluster here. What I have is somewhat conflicting information.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I took a look at the output from the HCP health-state analysis output a few days back. No dramatic feedback, just some general observation points for the most part. Until I got to the MVC-verifier section. The finding on all gateways in the Maestro cluster was that "MVC mode is OFF" and that this was "not set correctly on the SGM". I don't actually have any issues with the cluster state. Issuing a 'cphaprob stat' indicates that I have a healthy Maestro with all gateways ACTIVE.&amp;nbsp;&lt;/P&gt;&lt;P&gt;sk182829 indicates that this is deemed a perilous / non-standard state, however. It states that any Maestro (or Cluster of any kind?) should have MVC active if the GAIA OS version running is newer than R81.20 Take14. This Maestro is now running fine at Take158. (As is the rest of our fleet given recent security advisories). It's been patched quite a number of times since Take14 was released without any significant issues incurred.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have verified that MVC is definitely not active on all the SGMs within the Maestro. Issuing the 'cphaprob mvc' command returns a simple "OFF" response message on each member.&amp;nbsp;&lt;/P&gt;&lt;P&gt;So my questions from here are - considering that it appears MVC isn't as essential as the SK article leads us to believe - a) what are the down-sides with leaving it off? and b) are there any known implications around activating MVC? Traffic interruptions? Any other hits to service?&lt;/P&gt;&lt;P&gt;Thanks for any insights anyone is able to provide.&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Scordy&lt;/P&gt;</description>
    <pubDate>Fri, 31 Jul 2026 00:12:37 GMT</pubDate>
    <dc:creator>scordy</dc:creator>
    <dc:date>2026-07-31T00:12:37Z</dc:date>
    <item>
      <title>MVC mode is off</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/MVC-mode-is-off/m-p/280564#M4348</link>
      <description>&lt;P&gt;Hi All. This is probably just a general appeal for comments / feedback. I don't actually have a fault or problem condition on the Maestro cluster here. What I have is somewhat conflicting information.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I took a look at the output from the HCP health-state analysis output a few days back. No dramatic feedback, just some general observation points for the most part. Until I got to the MVC-verifier section. The finding on all gateways in the Maestro cluster was that "MVC mode is OFF" and that this was "not set correctly on the SGM". I don't actually have any issues with the cluster state. Issuing a 'cphaprob stat' indicates that I have a healthy Maestro with all gateways ACTIVE.&amp;nbsp;&lt;/P&gt;&lt;P&gt;sk182829 indicates that this is deemed a perilous / non-standard state, however. It states that any Maestro (or Cluster of any kind?) should have MVC active if the GAIA OS version running is newer than R81.20 Take14. This Maestro is now running fine at Take158. (As is the rest of our fleet given recent security advisories). It's been patched quite a number of times since Take14 was released without any significant issues incurred.&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have verified that MVC is definitely not active on all the SGMs within the Maestro. Issuing the 'cphaprob mvc' command returns a simple "OFF" response message on each member.&amp;nbsp;&lt;/P&gt;&lt;P&gt;So my questions from here are - considering that it appears MVC isn't as essential as the SK article leads us to believe - a) what are the down-sides with leaving it off? and b) are there any known implications around activating MVC? Traffic interruptions? Any other hits to service?&lt;/P&gt;&lt;P&gt;Thanks for any insights anyone is able to provide.&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Scordy&lt;/P&gt;</description>
      <pubDate>Fri, 31 Jul 2026 00:12:37 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/MVC-mode-is-off/m-p/280564#M4348</guid>
      <dc:creator>scordy</dc:creator>
      <dc:date>2026-07-31T00:12:37Z</dc:date>
    </item>
    <item>
      <title>Re: MVC mode is off</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/MVC-mode-is-off/m-p/280567#M4349</link>
      <description>&lt;P&gt;Short answer, it would only be an issue if you added a new SGM. This is a specific R81.20 quirk, in any other version it would be expected that MVC remains off in normal conditions. You can safely leave it off if you're not adding new SGMs, and it doesn't need to be enabled on the existing members before you upgrade to an R82 version.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Basically, this is something that only affects R81.20 versions before and after JHF take 14. JHF updates after take 14 aren't affected, but if you added a fresh SGM with base R81.20 on it, you'd have cluster problems. Hence we have the alert in HCP. The JHF install usually enables MVC but that might have been removed from the JHF at this point. Most R81.20 Maesto installs I've seen have MVC enabled but in your case, with the caveats noted here, you're fine to leave it off for now.&lt;/P&gt;</description>
      <pubDate>Fri, 31 Jul 2026 01:36:44 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/MVC-mode-is-off/m-p/280567#M4349</guid>
      <dc:creator>emmap</dc:creator>
      <dc:date>2026-07-31T01:36:44Z</dc:date>
    </item>
  </channel>
</rss>

