Showing results for 
Search instead for 
Did you mean: 

The mystery of Centralized Management a.k.a 'clustering'

Martin Eppler

Hello IronPort community.

In today's blog I try to demystify a bit the Centralized Managment feature, more known under the name 'Cluster'. Based on the amount of service request being received by us in support I know that this feature is causing some headache and a good source of confusion.

Before seeing what this feature does, we need to clarify what it is not: it is not providing any load balancing capabilities nor is it an active/standby configuration. Even when Centralized Management is in use, each of the appliances in the 'cluster' will handle it's own SMTP sessions and messages.

That said, what is then the Centralized Managment feature good for? The simple answer is: to share the same configuration across muliple appliances. When using the feature, it is not important on which of the appliances in the cluster the configuration change is done and committed, it will be ported to the other appliances as well. Just the configuration - not any queueud mail messages, quarantined messages or message tracking/reporting data.

Okay, so how can we get this feature to work?

Everything starts with the Centralized Management feature key, that must be present on all Email Security Appliances that form later on the cluster. Also it is mandatory that all appliances in the same cluster configuration hold the same AsyncOS release. The Security Management  Appliance does not share the configuration of the Email Security Appliance and is therefore outside of the cluster and feature scope. So don't be surprised when you do not receive a feature key for your M-Series appliance then as this is an Email Security Appliance feature only It is also important that the name of your IP Interfaces is the same across all appliances in the cluster as otherwise your Listeners cannot bind to them anymore which will cause headache and a non working listener.

Just as a side note: there is an M-Series feature key called 'Centralized Configuration Manager', but this one is used for managing Web Security Appliances. It has nothing to do with the Email Security Centralized Management feature.

We need to consider some requirements in the network. Port 22 or 2222 (depending if you'll use SSH or CCS for the cluster) needs to be open on a possible firewall. Also the hostname of the appliances must have a valid PTR record in the DNS for the IP the cluster communication connection is established to. If no PTR is present, then the cluster cannot set up the connection.

Now it's time to decide if you want to use the Cluster Communication Service (CCS, port 2222) or SSH (port 22) for the appliances to communicate with each other.  You can select different ports if you like to, the 22 and 2222 are the default values in use. Depending on this, you can then log into the CLI of the appliances and run the clusterconfig commands as indicated in the AsyncOS Advanced User Guide section 'Centralized Management'.

The cluster is configured, but what is the difference between machine level, group level and cluster level?

Not every configuration can be shared across all appliances in the cluster, as this would confuse the rest of the world (and your other network elements). The target is to provide a working configuration on all appliances and not to duplicate them. So some configurations are appliance specific and they are then configured on machine level. Most famous settings on this level are the IP address, the hostname and the default gateway. As a rule of thumb: every configuration that would cause issues when active on all appliances at the same time must be installed on machine level.

All other configuration (LDAP profiles and queries, Listeners, SMTP Routes, Content Filters, Mail Policies, etc) can be shared across multiple appliances in the cluster and therefore should not be applied on machine level (doing so would obsolete the entire clustering idea). They can go either to group or cluster level. The cluster level is the top level of administration and represents all appliances connected in the cluster. The group level can be established as a sub level of the cluster to organize appliances either in the same location or for the same purpose (e.g. inbound traffic vs. outbound traffic, Europe vs. US location, etc.). The group level is optional and by default not present when initializing the cluster. Configuration changes carried out on group level are only affecting appliances that are member of this given group.

A last note on 'who wins if I have a different configuration on diffferent levels': The order is bottom to top which means the machine level will always override any settings done on cluster level. So if you decide to disable the external spam quarantine on a specific appliance machine level, neither the group nor the cluster level configuration will match here (even when the external spam quarantine is turned on here). The group level outnumbers the cluster level configuration but is outnumbered by the machine level.

I hope I was able to bring some light on this topic. If not, please feel free to comment or get in touch with us in support.

Thanks for reading,


Martin Eppler

I forgot to mention one configuration step when using CCS that causes a lot of trouble:

If you wonder why you receive 'Authentication Failure' when adding a new appliance to the cluster, this might be based on the fact that after the clusterconfig -> prepjoin on the first appliance the commit was not done right after this.


Heh...more confusion from reading this article....

The "Cisco IronPort Centralized Web Configuration Manager" showed up in the SMA not the ESA with ESA in clustered configuration.   The ESA, in clustered configuration' does not have the feature mentioned.  So I guess the ESA feature actually shows up in SMA.   

Ken Stieers

That stuff is for managing WSA (you can use the SMA to manage Web Security Appliances also).


I see.... we don't have WSA so I suppose that feature is not needed.


Yes, I agree. The naming convention is a bit confusing...

"Centralized Management" has been a feature key for the ESA that was required to put ESAs into a Cluster (basically it enabled the 'clusterconfig' CLI command). Starting AsyncOS 8.5 this feature key is no longer needed and does no longer show up in the feature key list. It was obsoleted when the virtual appliances came to life.

"Cisco IronPort Centralized Web Configuration Manager" is a feature key on the SMA (and only on the SMA) that allows the configuration push to the WSA appliances. It has nothing to do with clustering ESAs and is therfore not required for email services.

Hope this helps to clear up the confusion...

Best regards,



Yup, perfect....


This is good info.

I'm doing a deployment now. I confirmed the basic config on the primary ESA then I configured just the IP information and gave the name of the interface of the primary 2 the second ESA Interface then I did the CCS cluster.  now its all grey out.  now i go to the SMA and add the primary to the SMA and I can now administer the ESA

Hello Martin, 

Seems you still response to this article. I have single query. 

you mentioned below 

"Also the hostname of the appliances must have a valid PTR record in the DNS for the IP the cluster communication connection is established to. If no PTR is present, then the cluster cannot set up the connection."

My question is why DNS record is mandatory? I can hook up two ESA in one cluster by IP address too right? else my cluster will become dependent on DNS server availability. can please clarify your point of view?