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.
I have a two node deployments, Primary Admin/MNT/PSN and Secondary Admin/MNT/PSN running ISE version 2.6 patch 2. This morning when I attempted to patch them with patch 3. I see this message in console: Application patch installation failed; Server=ISE_no...
Hi Community team, I need your help with the next case, maybe someone had the same issue I have a ASA5550 with 3 interface:- DMZ, INSIDE, OUTSIDE We have UDP traffic syslog from some host in the INSIDE LAN to the one server i...
Hello, We are using virtual ISE 2.4 patch 9 on VMWare. We also have a windows 2012 server as the DC on CA server. We are trying to authenticate a vm Win10 that is directly connected to a cisco 3850 switch. It works with PEAP/MSCHAPv...