<?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 Re: IPv6 on Maestro a nightmare... in Hyperscale Firewall (Maestro)</title>
    <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/197907#M2319</link>
    <description>&lt;P&gt;We once had a problem after an RMA where not all packets are forwarded any time. Looked like&amp;nbsp; a faulty downlink and after initial diagnostic we also got instructions to reboot all SGMs at once because&amp;nbsp;the bond interface numbering wasn't alligned&amp;nbsp;between the SGMs. The RMAed had 1,2,3,4 and the two unchanged had 1,4,5,6. We then rebooted just the unchanged devices one at a time and they came back with correct numbering.&lt;/P&gt;&lt;P&gt;You can check and compare the bond interface numbering with this command on each SGM:&lt;BR /&gt;cat /proc/net/bonding/bond1 |grep -A 5 -e "Interface:" -e "details actor lacp pdu"|grep -e "Interface:" -e "port number"&lt;BR /&gt;The output should look like:&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth1-05&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 1&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth2-05&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 2&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth2-07&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 3&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth1-07&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 4&lt;/FONT&gt;&lt;BR /&gt;or at least the same port numbering on all.&lt;/P&gt;</description>
    <pubDate>Tue, 14 Nov 2023 09:28:46 GMT</pubDate>
    <dc:creator>Axel_Pabich</dc:creator>
    <dc:date>2023-11-14T09:28:46Z</dc:date>
    <item>
      <title>IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/169862#M1414</link>
      <description>&lt;P&gt;Since some weeks we are trying to use IPv6 on a R81.10 Maestro environment. There are some really bad limitations:&lt;/P&gt;
&lt;P&gt;Enabling IPv6 in the whole environment needs a restart of all a appliances (MHO and SG) at the same time.&lt;/P&gt;
&lt;P&gt;Changing everything for the IPv6 configuration (IPs, routes etc.) end up in complete stop of processing all traffic for about 3-5min. In our VSX environment all VSs are affected not only the one with the changes.&lt;/P&gt;
&lt;P&gt;We are working with loacal engineers and it looks like there are some documents describing this issues, but they are not available outside of Check Point.&lt;/P&gt;
&lt;P&gt;There are no limitations mentioned in the Maestro limitations regarding this problems with IPv6&amp;nbsp;&lt;A title="Known Limitations for Scalable Platforms (Maestro Appliances and Chassis)" href="https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&amp;amp;solutionid=sk148074" target="_blank" rel="noopener"&gt;Known Limitations for Scalable Platforms (Maestro Appliances and Chassis)&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;Are we the only one using IPv6 on Maestro R81.10 ? Would be happy to get some experience from others and a statement from Check Point.&lt;/P&gt;
&lt;P&gt;Changing a route or an IP address should be something which can be done without any traffic loss.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 01 Feb 2023 06:15:58 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/169862#M1414</guid>
      <dc:creator>Wolfgang</dc:creator>
      <dc:date>2023-02-01T06:15:58Z</dc:date>
    </item>
    <item>
      <title>Re: IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/169876#M1415</link>
      <description>&lt;P&gt;All IPv6 restrictions and Maestro features are described in this SK's:&lt;/P&gt;
&lt;P&gt;&lt;A href="https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&amp;amp;solutionid=sk163313&amp;amp;partition=Basic&amp;amp;product=Quantum" target="_self"&gt;IPv6 features and limitations in R80.30 and higher &lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&amp;amp;solutionid=sk173183" target="_self"&gt;Scalable Platforms (Maestro and Chassis) comparison between versions &lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 01 Feb 2023 09:35:51 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/169876#M1415</guid>
      <dc:creator>HeikoAnkenbrand</dc:creator>
      <dc:date>2023-02-01T09:35:51Z</dc:date>
    </item>
    <item>
      <title>Re: IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/169929#M1416</link>
      <description>&lt;P&gt;I think isn't a specific issue related to IPv6, but is a problem with VSX on Maestro.&lt;/P&gt;&lt;P&gt;In my company we've maestro setups with one security group each, some of them we're working with 3 vsx per sg, we faced some issues, where we need to reboot all SGMs simultaneously and this caused a huge impact for us.&lt;/P&gt;&lt;P&gt;The cases opened with TAC weren't able to find out the root cause, but they explained when a VSX is down, for MHO the whole SGM are considered down as well.&lt;/P&gt;&lt;P&gt;I've installed the HF81 for R81.10 last weekend and seems something was improved, since I didn't face any issue and in the same maintenance window, I created 2 new VSX.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 01 Feb 2023 14:06:45 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/169929#M1416</guid>
      <dc:creator>cassiomaciel</dc:creator>
      <dc:date>2023-02-01T14:06:45Z</dc:date>
    </item>
    <item>
      <title>Re: IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/197907#M2319</link>
      <description>&lt;P&gt;We once had a problem after an RMA where not all packets are forwarded any time. Looked like&amp;nbsp; a faulty downlink and after initial diagnostic we also got instructions to reboot all SGMs at once because&amp;nbsp;the bond interface numbering wasn't alligned&amp;nbsp;between the SGMs. The RMAed had 1,2,3,4 and the two unchanged had 1,4,5,6. We then rebooted just the unchanged devices one at a time and they came back with correct numbering.&lt;/P&gt;&lt;P&gt;You can check and compare the bond interface numbering with this command on each SGM:&lt;BR /&gt;cat /proc/net/bonding/bond1 |grep -A 5 -e "Interface:" -e "details actor lacp pdu"|grep -e "Interface:" -e "port number"&lt;BR /&gt;The output should look like:&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth1-05&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 1&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth2-05&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 2&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth2-07&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 3&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;Slave Interface: eth1-07&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;port number: 4&lt;/FONT&gt;&lt;BR /&gt;or at least the same port numbering on all.&lt;/P&gt;</description>
      <pubDate>Tue, 14 Nov 2023 09:28:46 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/197907#M2319</guid>
      <dc:creator>Axel_Pabich</dc:creator>
      <dc:date>2023-11-14T09:28:46Z</dc:date>
    </item>
    <item>
      <title>Re: IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/200466#M2348</link>
      <description>&lt;P&gt;We've had a change of some bonds last night and few issues afterwards:&lt;/P&gt;&lt;P&gt;- some IPv6 routes went missing after changing bond configuration. We did few different changes with bond1, but some directly connected IPv6 routes were missing even from other bond interfaces.&amp;nbsp;&lt;/P&gt;&lt;P&gt;- one SGM crashed after deleting one member of a bond. Once it came back, IPv6 routes on that SGM were fine, but two other SGMs lost some IPv6 routes (including connected ones).&lt;/P&gt;&lt;P&gt;- MAC addresses have changed on the bond we modified and were inconsistent between SGMs. Even SGM reboots (one at a time) did not fix it. We had to remove all except one bond members, reboot SGMs which had wrong MAC addresses (one at a time) and when all SGMs have agreed on MAC addresses, we have added remaining interfaces to bond. And we had to fix IPv6 again at the very end.&lt;/P&gt;&lt;P&gt;Fixing IPv6 routes for us involved doing &lt;STRONG&gt;state off&lt;/STRONG&gt; / &lt;STRONG&gt;state on&lt;/STRONG&gt; for IPv6 subinterfaces (luckily, just a handful of them)&lt;/P&gt;&lt;P&gt;This is single security group and security gateway (not a VSX), R81.10 JHF T66.&lt;/P&gt;</description>
      <pubDate>Wed, 13 Dec 2023 12:25:06 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/200466#M2348</guid>
      <dc:creator>Srdjan_B</dc:creator>
      <dc:date>2023-12-13T12:25:06Z</dc:date>
    </item>
    <item>
      <title>Re: IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/200470#M2349</link>
      <description>&lt;P&gt;For reference some of these issues appear resolved in more recent Jumbo takes.&lt;/P&gt;</description>
      <pubDate>Wed, 13 Dec 2023 12:34:55 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/200470#M2349</guid>
      <dc:creator>Chris_Atkinson</dc:creator>
      <dc:date>2023-12-13T12:34:55Z</dc:date>
    </item>
    <item>
      <title>Re: IPv6 on Maestro a nightmare...</title>
      <link>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/200502#M2350</link>
      <description>&lt;BLOCKQUOTE&gt;&lt;HR /&gt;&lt;a href="https://community.checkpoint.com/t5/user/viewprofilepage/user-id/66196"&gt;@cassiomaciel&lt;/a&gt;&amp;nbsp;wrote:&lt;BR /&gt;&lt;P&gt;I think isn't a specific issue related to IPv6, but is a problem with VSX on Maestro.&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;That's interesting and good to know. It confirms our decision not to replace our 61k/64k with Maestro.&lt;/P&gt;</description>
      <pubDate>Wed, 13 Dec 2023 14:57:59 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Hyperscale-Firewall-Maestro/IPv6-on-Maestro-a-nightmare/m-p/200502#M2350</guid>
      <dc:creator>Vincent_Bacher</dc:creator>
      <dc:date>2023-12-13T14:57:59Z</dc:date>
    </item>
  </channel>
</rss>

