Configuration Sync Across Gateways (Maestro Light) using 3rd party Packet Broker

[Garrett_DirSec]

Hello All -

I'm collecting data on various gateway architectures for customer for unique use case.

General Requirements:

1. Large outbound traffic.
2. No need for state and session failover (ie. clusterXL)
3. Prefer full use of throughput for each gateway comprising "cluster". 
4. Potentially use more than 2x gateway devices for "cluster".  
5. Easy add/remove of devices (assume same make/model).

It's unclear if customer needs cost and associated technical training for Maestro.

Customer does have existing relationship with Packet Broker vendor (example:    Garland Technologies or Niagra Networks).

The packet broker device would operate like a much-simplified Maestro controller.

Questions:

1. Is there a way to treat N-number of CP gateway objects as ONE device for mgmt simplicity?      Example: if we leverage ClusterXL and somehow turn OFF state and session sync, there is typically ONE layer2 MAC address owned by clusterXL service.  
2. I perceive we simply need to have N-number of separate CP gateway objects created -- all receiving same security policy.   The "upstream" packet broker will be handling the inbound client connection, distribution to CP gateway, and persistence of connection based on various session properties.

Any obvious problems with this approach?   Thanks -GA

[PhoneBoy]

You may want to consider ElasticXL in R82, which gives you the single management object for up to 3 members.
Scalability numbers haven't been published yet.

Otherwise, you'll have to create N number of gateways and use a packet broker, as you've suggested.

[Garrett_DirSec]

Hello @PhoneBoy -- thanks for your insight.   very much appreciated!!    

Yes -- Elastic XL looks super interesting.   Heiko has posted some very helpful information threads. 

posted here simply to benefit others ... 

ElasticXL - Installation 

ElasticXL - Overview

[Bob_Zimmerman]

This seems like a lot of effort for a topology which is unlikely to ever work very well.

You can use a ClusterXL cluster object for a cluster without state sync. Under the ClusterXL and VRRP section, uncheck Use State Synchronization. I think High Availability > VRRP should make all cluster members effectively active, so they'll process whatever traffic is sent to them. You could use Active-Active clustering, but it has some topology concerns.

You might need to tweak the cluster monitoring config to get it to stop the members from trying to talk to each other on their clustered interfaces.

A multicast load sharing cluster is likely to work much better, and would actually be supported.