topic Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices? in Hyperscale Firewall (Maestro)

Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

katarina_ — Wed, 16 Apr 2025 07:30:57 GMT

Hello Community,

we’re preparing for a Check Point Maestro + ACI implementation and would appreciate any input or best practices.

Our environment and Architecture:

Platform: Check Point Maestro (2x 9700 SGMs + MHO-140)
Software: R81.20
Bonding mode: 802.3ad (LACP)
Each bond connects to ACI fabric (2x Leafs) – currently working with 25G SR links
One VS per ACI context (stage/prod)
L3 IPs assigned directly to bond interfaces

One-arm mode
Policy-Based Routing (PBR)
Interfaces connected to ACI (via LACP bundles)

Are there best practices for one-arm PBR design with Maestro + ACI?
What’s the recommended interface setup for L3 one-arm traffic into VSX (e.g., VLAN tagging, IP on bond, subinterfaces)?
Any special considerations with LACP bonding on Maestro?

Any insights or shared experiences would be super helpful – we already resolved one port-down issue by hardcoding 25G speed on CP side (vs 10G default), so we’d love to avoid surprises during full implementation.

Thank you!

Katarina

Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

_Val_ — Tue, 22 Apr 2025 10:28:17 GMT

@Lari_Luoma, @Anatoly can you advise?

Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

Lari_Luoma — Tue, 22 Apr 2025 18:25:43 GMT

Hello @katarina_

With ACI service graphing and PBR is the recommended setup. You are correctly using VSX with a VS per tenant in one-arm mode. That's the best practice. Using trunked bonds is more scalable solution in my opinion. It needs fewer physical interfaces, and you can add more VLANs into a trunk when necessary. Then you would assign a VLAN from the trunk to each VS. With one-arm mode you should keep anti-spoofing disabled from the interface.

The only limitation with LACP is that the bond members need to be connected to the same logical switch. In ACI you most likely have vPC enabled on leaf switches anyway, so you should be covered. My recommendation is to hard code the speed for the uplinks at the MHO.

Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

Lari_Luoma — Tue, 22 Apr 2025 18:28:31 GMT

Let me also add that you might want to engage with Check Point Professional Services. PS has a long experience with the best practices setups including the ACI environments.

Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

AaronCP — Wed, 23 Apr 2025 18:47:07 GMT

Hi @katarina_,

We've recently deployed Maestro & VSX with Cisco ACI using Symmetric PBR and have deployed it similar to how you've described. Here are a couple of things I've learned during the process:

You'll need to add a rule to permit Service Graph Health Group probes. You can configure the probe on the APIC to use ICMP, HTTPS, etc. If the rule doesn't exist, the Service Graph won't work.
If your magg0 interface is connected to the leaf switches, you'll need to disable the "IP dataplane learning" feature for the magg0 bridge domain subnet on the APIC to avoid management connectivity issues.
If you're planning to enable dynamic balancing, there's a known issue where the mq_mng process runs multiple times, causing high CPU. I believe this is resolved in T99 (I'll try and dig out the PRJ reference).
The 25G autonegotiation issue is an ACI-side issue. We found by hardcoding the leaf switch interface, bouncing the interface, then setting it back to autonegotiation and bouncing the interface again sorted it. That's far from ideal. We were concerned about what the potential impact would be if the leaf switch reloaded and multiple interfaces failed to negotiate correctly. A case was raised with Cisco TAC who confirmed it is a bug. We've now set the interfaces on the leaf switch to use the "Inherit" setting (Cisco's recommendation) and we've not had any issues since.
Not an ACI-specific issue, but definitely a Maestro & VSX one is the use of Generic Data Centre objects in policy. If you're planning on using them in your Virtual System firewall policies, you'll need to create a dummy drop rule on VS0 as a workaround in order for the feature to work (R&D are currently working on a fix for this).
Integrating the SMS/MDS with the Cisco APIC (using the Cloudguard Controller Cisco ACI object) is a great way of automating parts of your rulebase. It allows you to use the EPGs/ESGs as objects in the firewall policy, meaning if a new endpoint is added to an EPG on the fabric, it will automatically be included in any firewall rules associated with the EPG/ESG. This feature is not impacted by the Generic Data Centre issue mentioned above.

If I think of any more, I'll add them here.

Thanks,

Aaron.

Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

AaronCP — Wed, 23 Apr 2025 20:13:15 GMT

To clarify, the dummy drop rule for VS0 should contain the objects pulled in from the Generic Data Centre object. This is so the objects get loaded on VS0 so that they can be used by the Virtual System(s).

Re: Implementation Check Point VSX + Maestro s ACI (LACP, One-arm, PBR) – best practices?

katarina_ — Mon, 28 Apr 2025 08:55:20 GMT

Hi @Lari_Luoma,

Thank you very much for your response, I have already hard-coded the speed, as I encountered this issue at the beginning.