IPv6 on Maestro a nightmare...

[Wolfgang]

Since some weeks we are trying to use IPv6 on a R81.10 Maestro environment. There are some really bad limitations:

Enabling IPv6 in the whole environment needs a restart of all a appliances (MHO and SG) at the same time.

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.

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.

There are no limitations mentioned in the Maestro limitations regarding this problems with IPv6 Known Limitations for Scalable Platforms (Maestro Appliances and Chassis)

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.

Changing a route or an IP address should be something which can be done without any traffic loss.

[HeikoAnkenbrand]

All IPv6 restrictions and Maestro features are described in this SK's:

IPv6 features and limitations in R80.30 and higher

Scalable Platforms (Maestro and Chassis) comparison between versions

[cassiomaciel]

I think isn't a specific issue related to IPv6, but is a problem with VSX on Maestro.

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.

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.

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.

[Axel_Pabich]

We once had a problem after an RMA where not all packets are forwarded any time. Looked like  a faulty downlink and after initial diagnostic we also got instructions to reboot all SGMs at once because the bond interface numbering wasn't alligned 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.

You can check and compare the bond interface numbering with this command on each SGM:
cat /proc/net/bonding/bond1 |grep -A 5 -e "Interface:" -e "details actor lacp pdu"|grep -e "Interface:" -e "port number"
The output should look like:
Slave Interface: eth1-05
port number: 1
Slave Interface: eth2-05
port number: 2
Slave Interface: eth2-07
port number: 3
Slave Interface: eth1-07
port number: 4
or at least the same port numbering on all.

[Srdjan_B]

We've had a change of some bonds last night and few issues afterwards:

- 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. 

- 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).

- 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.

Fixing IPv6 routes for us involved doing state off / state on for IPv6 subinterfaces (luckily, just a handful of them)

This is single security group and security gateway (not a VSX), R81.10 JHF T66.

[Chris_Atkinson]

For reference some of these issues appear resolved in more recent Jumbo takes.

[Vincent_Bacher]

---

@cassiomaciel wrote:

I think isn't a specific issue related to IPv6, but is a problem with VSX on Maestro.

That's interesting and good to know. It confirms our decision not to replace our 61k/64k with Maestro.