topic Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro" in Hyperscale Firewall (Maestro)

limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro" still exist ?

Wolfgang — Wed, 26 Oct 2022 14:15:12 GMT

I'm not sure but this limitations still exists in R81.10? LACP not possible with management interfaces with Maestro?

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Dario_Perez — Wed, 26 Oct 2022 14:31:20 GMT

Hi is fully supported on R81.10 maestro and chassis.

Documentation will be updated soon

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Chris_Atkinson — Wed, 26 Oct 2022 14:34:45 GMT

Believe the documentation is being amended to confirm this is now supported in R81.10

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

MartinTzvetanov — Mon, 31 Oct 2022 10:59:29 GMT

I did an installation of Maestro with R81.10 and used the latest JHF available at that time (66 I believe) and couldn't make it work for magg. The same configuration works perfect for the management ports of Maestro itself and downlinks but not for magg.

Forgot to mention - I talk about configuring magg and lacp for Cisco VPC

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Lari_Luoma — Mon, 31 Oct 2022 14:37:27 GMT

There is one limitation to what @Dario_Perez mentioned. If you intend to share the management interface between security groups, LACP is still not supported.

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Timothy_Hall — Mon, 31 Oct 2022 21:54:30 GMT

Is this because only the SMO Master participates in LACP and if you are sharing the management interface between Security Groups you can't have more than one SMO Master trying to do LACP with the management port?

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Lari_Luoma — Mon, 31 Oct 2022 21:59:55 GMT

This sounds like it, but the definitive answer should come from R&D. @Anatoly

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Derrick_Durbin — Wed, 16 Nov 2022 21:05:19 GMT

Any word on this being updated in the R81.10 admin guide?

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 13:48:48 GMT

What kind of issues were you facing? I have a Maestro VSX environment running Dual-Site, Single-Orch, and it's behaving strangely. This is running R81.20 + JHF Take 24, so it should be supported.

We are seeing a ton of these messages in /var/log/messages on all Security Group members:

kernel:magg0: An illegal loopback occurred on adapter (eth1-Mgmt1)

kernel:Check the configuration to verify that all adapters are connected to 802.3ad compliant switch ports

kernel:magg0: An illegal loopback occurred on adapter (eth1-Mgmt2)

I have verified both the Check Point side of things and the switch side of things. Everything should be good. But these messages keep on appearing. This is my first time running 802.3AD/LACP on magg, everyone else I'm working with is running XOR.

There is only a single Security Group, not being able to share magg shouldn't be a problem. Unless "Dual-Site" and the fact that we have two chassis as a result of this also counts as "shared"?

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Wolfgang — Wed, 30 Aug 2023 14:18:03 GMT

@RamGuy239 to be sure, did you checked twice your DualSite deployment. The magg0 should be build with interfaces from one site, only. Meaning from only one MHO in your described deployment.

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 14:37:24 GMT

Hmm.. Is this true when you have a Single Orch per site in a dual-site configuration? From the documentation, this isn't very clear. It mentions, "Important - When you connect two Quantum Maestro Orchestrators for redundancy, the Check Point Management Server connects only to one of the Quantum Maestro Orchestrators."

We don't have "redundancy" per se, as we only have a single orchestrator per site/chassis. How would this work? Site 2 is a disaster recovery site if there is a power outage, fire, flood, etc., taking out Site 1. How would Site 2 operate if it has no magg connections located on Site 2?

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 14:43:37 GMT

The wording in the admin guide is also quite confusing. It only states that the management will only send traffic to one orchestrator. This makes sense as the management sends all traffic to the SMO, then the SMO spreads it across the security group members. This doesn't tell me much regarding magg should only be connected to a single orchestrator. This doesn't make any sense to me from a logical standpoint. So if Site 1 goes down, the Orchestrator with it, the SMO moves to Site 2 but is supposed to incapable of receiving management traffic?

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Wolfgang — Wed, 30 Aug 2023 14:48:11 GMT

@RamGuy239 I agree, the documentation regarding Dual Site deployment isn't clear. In short and simple ... you have to configure all on only one site and the other will be a "copy" of your first.

You configure one mgmt interface on your MHO and the corresponding interface on the other MHO will be used automatically. No configuration is needed if you deploy DUAL SITE. No LACP bond with interfaces from both sites needed. Failover of MGMT will be done if site 1 goes down.

You can configure a magg with two interfaces from site 1 to your switch-environment on site 1. And the same is used on the other site with no need for an extra configuration on site 2. All what is needed ... you have to define the environment as dual site and define where your MHOs are located (site 1 or 2).

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 14:53:11 GMT

This is basically what we have already. Site 1 and Site 2 are identical in terms of configuration. Port 1-2 is used on both Orchestrators, and the same ports are used for downlink on both sides. The only difference is that Site 1 consists of 3x CPAP-SG6600 appliances, while Site 2 consists of 2x CPAP-SG6500 appliances.

magg0 is configured with LACP and this made the most sense to us as it is supported on R81.20. I can't see a single reason to opt for XOR over LACP when LACP is supported? So judging by your comment nothing is wrong with our setup. Started to worry about missing something crucial here when you started mentioning that Orch2 shouldn't be connected to magg at all.

Which brings us back to the messages from /var/log/messages.

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Wolfgang — Wed, 30 Aug 2023 14:59:03 GMT

If the site1 goes down the SMO moves to site 2 and the configuration of the management interface moves too. Sounds something magic but it's how it works. There is no need to add interfaces from the other site in the SGs configuration.

I fully agree your confusion. It was the same to me with our first Dual Site deployment.

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Wolfgang — Wed, 30 Aug 2023 15:07:08 GMT

@RamGuy239 again. If you run DUAL SITE deployment, only interfaces from one site should be attached your SG configuration.

See my screenshot in last post.

And no BOND should be configured with interfaces from both sites !

To be sure we are talking about the same DUAL SITE...You have these settings on your MHOs?

site 1
set maestro configuration orchestrator-site-amount 2
set maestro configuration orchestrator-site-id 1
set maestro port 1/47/1 type site_sync

site 2
set maestro configuration orchestrator-site-amount 2
set maestro configuration orchestrator-site-id 2
set maestro port 1/47/1 type site_sync

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 15:05:37 GMT

Pretty sure this equals to what we currently have going:

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
Use RxHash: 0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: 00:1c:7f:aa:bb:00
Active Aggregator Info:
Aggregator ID: 4
Number of ports: 2
Actor Key: 15
Partner Key: 19
Partner Mac Address: 00:04:96:9b:bd:09

Slave Interface: eth1-Mgmt1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:1c:7f:a4:2d:d2
Slave queue ID: 0
Aggregator ID: 4
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: 00:1c:7f:aa:bb:00
port key: 15
port priority: 255
port number: 1
port state: 61
details partner lacp pdu:
system priority: 0
system mac address: 00:04:96:9b:bd:09
oper key: 19
port priority: 0
port number: 1019
port state: 61

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 15:12:12 GMT

No configuration for magg on the security group? At all? How would one make magg into LACP then? Which is supposedly supported? Not sure how I can revert this? I don't think manually removing magg0 in the configuration is a smart move?

add bonding group 0 mgmt
set bonding group 0 mode 8023AD
set bonding group 0 lacp-rate slow
set bonding group 0 min-links 0
set bonding group 0 mii-interval 100
set bonding group 0 primary eth1-Mgmt2
set bonding group 0 down-delay 200
set bonding group 0 up-delay 200
set bonding group 0 xmit-hash-policy layer3+4

Compared to another enviroment I have running, without LACP it looks like this:

add bonding group 0 mgmt
set bonding group 0 mode xor
set bonding group 0 xmit-hash-policy layer2

Only real difference is how we have deployed LACP, not XOR? I can't locate anything in the admin guide telling us to not run the bonding commands on the security group?

It specifically tells us to do it, and doesn't mention anything about avoiding it on Dual-Site?
https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_Maestro_AdminGuide/Content/Topics-Maestro-AG/Configuring-Bond-Interface-on-Management-Ports.htm?Highlight=magg

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

Wolfgang — Wed, 30 Aug 2023 15:25:35 GMT

Yes, that's annoying in the documentation.

In your case with only one MHO on both sites you can configure a magg with two interfaces from one MHO. and these configured magg will be failover automatically to the other site if the site goes down. The only thing to configure on the other site will be the switch LACP configuration . And there is no need for a LACP bond on the switches spanning over both sites. There should be one LACP channel on your switches at site 1 and another one on your switches at site 2.

Without redundancy at the same site you don't need a magg, only one interface should be used at site 1 and no configuration is needed at site 2.

Re: limitation "MAGG with LACP configuration is only supported in Chassis, not in Maestro"

RamGuy239 — Wed, 30 Aug 2023 15:56:31 GMT

But isn't this what we are already running? The bonding serves multiple purposes. We want to utilise both eth1-mgmt and eth2-mgmt, port 1 and port 2 on Orchestrator-1 (Site 1). This is because the customer wants both redundancy on port level and switch level. By utilising port 1 and port 2 like this, we create a scenario where port 1 or port 2 can fail, without magg dropping from Orchestrator-1. By running LACP using VPC on the switch side of things, the customer creates a scenario where they can reboot and patch switch-1 without dropping magg as it is also connected to switch-2.

A similar configuration is applied on Site-2, where Orchestrator-2 has the exact same configuration with port-1 connected to one switch and port-2 connected to another switch.

This makes the configuration in Gaia look like this on all five security group members:

add bonding group 0 mgmt
set bonding group 0 mode 8023AD
set bonding group 0 lacp-rate slow
set bonding group 0 min-links 0
set bonding group 0 mii-interval 100
set bonding group 0 primary eth1-Mgmt2
set bonding group 0 down-delay 200
set bonding group 0 up-delay 200
set bonding group 0 xmit-hash-policy layer3+4

This makes the bond look like this:

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
Use RxHash: 0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

Slave Interface: eth1-Mgmt2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:1c:7f:a4:2d:d2
Slave queue ID: 0
Aggregator ID: 4
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: 00:1c:7f:aa:bb:00
port key: 15
port priority: 255
port number: 2
port state: 61
details partner lacp pdu:
system priority: 0
system mac address: 00:04:96:9b:bd:09
oper key: 19
port priority: 0
port number: 1019
port state: 61

I don't think any of this is wrong. The configuration is identical for member 1_01-1_03 as it is on 2_01-2_02. What exactly is wrong with our configuration? I think we are talking past each other. I don't think we are required to change anything? The configuration is correct but for some reason, we are seeing these strange messages in /var/log/messages for whatever reason.

Or do you think the configuration is wrong?