Layer 4 Distribution - Yes or No?

[Timothy_Hall]

So it would appear that Layer 4 Distribution is enabled by default but the overall consensus seems to be to disable it unless you need it.  Is that still true in R81.10 or is that an outdated recommendation?  The issues that lead to that recommendation seemed to involve messing up the availability of SGM-offered web portals like UserChecks and the Captive Portal/Identity Awareness.  Looks like at one point L4 would mishandle fragmented traffic but that got fixed recently.  

Assuming this recommendation to disable L4 unless needed still holds true, would these scenarios be an accurate and complete representation of why you would need L4 in R81.10:

• There is a small amount of diverse source and destination IP addresses traversing the Security Group, but there are large amount of source ports in use by protocols such as HTTP, HTTPS, and possibly DNS. This results in the Security Group’s load becoming heavily unbalanced between the SGMs.

• The Security Group is NATting a very high percentage of traffic passing through it which is typical of a perimeter gateway, but not for a gateway inside the internal network or located in a Data Center.

Thanks!

[RickLin]

Interesting topic, I also would like to know what is recommended setting(enable or disable), and if R&D will try to change the mechanism in the roadmap?

[Lari_Luoma]

Hi Tim,

Current recommendation is to keep L4 distribution disabled unless there is a specific reason to enable it. The first scenario you mentioned is usually the case when you should consider enabling it. In a network with diverse IP-address space, L4 distribution doesn't give much benefit anyway.

In the second scenario the question is about the distribution mode. In the perimeter environment you should use auto-topology (default) and in internal gateway general mode.

[Timothy_Hall]

That's what I thought, thanks.  Just seems a little odd that L4 is enabled by default but the recommendation is to disable it.

[Lari_Luoma]

I agree, seems odd to me too. 🙂

[the_rock]

I think what @Lari_Luoma said makes perfect sense. If you think about it logically, really, even in complex environment, there is probably no need to enable this unless really necessary. 

[JaAnd]

Maybe in a dual site active-active configuration (not multi room, nor dual site active-backup) which was promised to us about 4 years ago, when Maestro was implemented, it could be beneficial to use L4.

In our case, as far as I understand, it would, as we could preferably process traffic on a source network basis - we use different networks for end user's access layer in two separate, but very well interconnected DCs.

Nevertheless still It's not officially supported, but was promised to us on a stage (!) on last's year CPX 😞

[alexgnunez2]

You're absolutely right—this is something that has been promised for quite some time, and it’s understandable that there’s anticipation for a dual site active-active configuration with Maestro. As you mentioned, using L4 in such a setup could indeed be beneficial, especially for processing traffic based on source networks in environments with well-interconnected data centers. This approach could optimize traffic distribution and improve redundancy, which is critical for high-availability architectures.

That said, I trust that Check Point is taking the time to ensure this feature is truly robust and functional before releasing it to the public. Implementing an active-active dual site configuration is inherently complex, and it’s crucial to avoid potential pitfalls that could arise in production environments. Rushing such a feature could lead to instability or unexpected issues, which would be far more detrimental in the long run.

From what I understand, Check Point has been working diligently on this, and while it’s not officially supported yet, it’s possible we might see progress or even a release next year. The complexity of synchronizing state tables, ensuring seamless failover, and maintaining performance across two active sites requires thorough testing and validation.

In the meantime, it’s worth keeping an eye on updates from Check Point, as they’ve been gradually improving Maestro’s capabilities. Hopefully, the wait will result in a solution that meets the high expectations of the community and delivers the reliability we need for such critical deployments.

[the_rock]

Yea, sounds in case you described, it would be beneficial.

Andy

[emmap]

Dual site A/A is supported and has been available via a special R81.10 release for a while now. It's also in R82, currently not yet GA but supported via RnD. If you would like to get involved and help us validate and direct development of it, please let us know via your local sales office. 

[Timothy_Hall]

Via the Solutions Center?

[emmap]

I'm not sure if it's Solution Centre directly or not, but they would know.

[Martin_Raska]

Could you elaborate more on Active/Active? Any SK? Limitations etc?

[Lari_Luoma]

• Active/Active mode allows two geographically remote data centers to be protected behind a single Security Group.
• Both sites can handle traffic simultaneously
• Traffic is synchronized between both sites
• Inter-site asymmetric traffic is supported due to inter-site correction
• Based on UIPS addresses (Unique IP-address per site)
• UIPS enables configuration of multiple addresses for each interface, with one address designated for each site. The UIPS configuration is set as an alias interface unique to all members within the same site.
• Traffic is distributed between the sites based on dynamic routing and UIPS.
• Each site has its DR Manager responsible for communicating with a third-party peer using its own UIPS.
• Through this communication, the third-party peer constructs its routing table, enabling it to accurately forward traffic to the appropriate site.
  
  Limitations
• IPv6 is not supported
• vsx_util reconfigure is not supported
• Proxy arp is not supported
• Anti-spoofing is supported only if defined by routes is used
• Bridge mode (L2) is not supported
• All limitations of ClusterXL Active/Active apply here except VSX, which is supported
• Managing via an uplink is not supported
• Since this is a new technology,  all deployments must be done in coordination with Check Point R&D until further notice.

Considerations

• Think if you really need active/active dual site or if you'd be good with two single sites. Two single site deployment would be simpler, but the connections are not synchronized.
• The main benefit in my opinion with A/A dual site is the support for asymmetric connections.

[alexgnunez2]

That's exactly what we need, but I would like to know more. Is there a thread where we can see the tests that have been done so far, or perhaps a recording of a webinar that shows things like implementation, traffic management, recommended scenarios, etc.?

[Lari_Luoma]

I think we could arrange such a webinar. @PhoneBoy 

[PhoneBoy]

Of course, let's talk 🙂

[JaAnd]

Thank you Lari for those valuable information, your webinaries about Maestro were always extremely helpful to me!

I will reach out our CP representatives then in this subject. I am just wondering how those UIPS are collected/configured? What puzzles me the most, is how to relate a VMware HA cluster, whose VLANs are stretched between those two DCs, to such Maestro active-active dual site topology. We would have to divide the networks of these VLANs between these DCs beforehand? 

[Lari_Luoma]

UIPS addresses are configured in gclish and all routing information in local CLISH per site. As you might have figured A/A dual site does not require networks to be stretched between the sites. If you do have such networks, they will work as with Active/Backup solution and the gateway for them will be on one site only. To make them work as active/active my understanding is that you would have to divide them between the DCs as you mentioned. If you need detailed configuration information, contact your account team and they are able to get you the most up-to-date instructions and help from R&D.

[alexgnunez2]

Hi emmpap,

As a customer, we were aware of the support for Dual site A/A via the special R81.10 release and its inclusion in R82, although not yet GA but supported via RnD. Unfortunately, only a few individuals within Check Point are aware of this, and this information has not been shared with partners where customers typically seek support.

Due to this lack of widespread knowledge and official communication, we decided to hold off on pursuing this topic until Check Point makes it publicly available.