11-11-2014 12:11 AM
I have opened a TAC ticket on this one but was curious if any others experienced the same issue.
I have C170s in Centralized ClusterConfig. I recently learned about the Virtual ESAs after reading about the EOL for C170s in a few years. I think the Virtual ESAs will add a lot of flexibility. The only issue I've noticed was trying to join Virtual ESAs to our Cluster are updates so far.
The first virtual ESA I brought up I was able to initially update it so it could join the cluster. I thought maybe I messed up the network config somewhere. So after messing with it over the Weekend and opening a TAC case with Cisco. I thought I would try configuring the second Virtual ESA. Sure enough updates are working, and no errors. Hooked it up enough to do some quick testing to make sure the listeners were working. Feeling pretty good about it, I join the cluster. Everything copied over configuration wise, I also setup a new ClusterGroup for the Virtual ESAs so I could customize the listeners and interfaces. Before I got too crazy I quickly realized that my updates stop working on the second virtual appliance.
So just curious if there are some configuration compatibility issues between appliance hardware and Virtual we should be aware of. I found some great information from the Forums about forcing updates and reading the tail of the updater_logs, which produced the following:
Info: Dynamic manifest fetch failure: Received invalid update manifest response
I found the fix for non-cluster configured Virtuals for this Update error:
http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118065-maintainandoperate-esa-00.html
But this does not for for clusterconfig.
So is my best course of action to:
Obviously I left out all the fine details about MX records, IP addresses, Central Reporting and Spam and outbreak reporting. Just want to make sure I'm not missing something, maybe tare down the old clusterconfig first, set it to point to the update servers in the article above. Then I can phase out my old physicals later on down the line as they break down over time and avoid configuring two clusters for every rule change.
11-11-2014 12:48 AM
So it looks like I have found the answer to my own question. Looks like the fix in the following article does apply to Virtual ESA in a cluster.
http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118065-maintainandoperate-esa-00.html
Some things I'd like to figure out is, will this change stick, will new virtual nodes pick up the incorrect update URL when I join them to the cluster? I made the changes and all my hosts seem to be updating fine. Will wait and see how well they do over the next few days and let them bake in a little before I push e-mail through them.
Step by Step how it looks with a cluster config from the CLI:
(Machine esa1.yourcompany.com)> updateconfig
Service (images):
Update URL:
--------------------------------------------------------------------------------
--------------------------------------
Feature Key updates
http://downloads.ironport.com/asyncos
RSA DLP Engine Updates
Cisco IronPort Servers
PXE Engine Updates
Cisco IronPort Servers
Sophos Anti-Virus definitions
Cisco IronPort Servers
IronPort Anti-Spam rules
Cisco IronPort Servers
Outbreak Filters rules
Cisco IronPort Servers
Timezone rules
Cisco IronPort Servers
Enrollment Client Updates (used to fetch certificates for URL Filtering)
Cisco IronPort Servers
Cisco IronPort AsyncOS upgrades
Cisco IronPort Servers
Service (list):
Update URL:
--------------------------------------------------------------------------------
--------------------------------------
RSA DLP Engine Updates
Cisco IronPort Servers
PXE Engine Updates
Cisco IronPort Servers
Sophos Anti-Virus definitions
Cisco IronPort Servers
IronPort Anti-Spam rules
Cisco IronPort Servers
Outbreak Filters rules
Cisco IronPort Servers
Timezone rules
Cisco IronPort Servers
Enrollment Client Updates (used to fetch certificates for URL Filtering)
Cisco IronPort Servers
Service (list):
Update URL:
--------------------------------------------------------------------------------
--------------------------------------
Cisco IronPort AsyncOS upgrades
Cisco IronPort Servers
Update interval: 5m
Proxy server: not enabled
HTTPS Proxy server: not enabled
Choose the operation you want to perform:
- SETUP - Edit update configuration.
- CLUSTERSET - Set how updates are configured in a cluster
- CLUSTERSHOW - Display how updates are configured in a cluster
[]>dynamichost
Enter new manifest hostname:port
[update-manifests.ironport.com:443]>update-manifests.sco.cisco.com:443
Choose the operation you want to perform:
- SETUP - Edit update configuration.
- CLUSTERSET - Set how updates are configured in a cluster
- CLUSTERSHOW - Display how updates are configured in a cluster
[]>
(Machine esa1.yourcompany.com)> commit
11-11-2014 06:53 PM
This setting can be set at each clustergroup level. (clustermode)
Cisco TAC confirmed that Virtual ESA need to have a different dynamichost then Physical Appliances. So it is important to plan this change into your clusterconfig, and set cluster groups for your physical appliances for update-manifests.ironport.com:443, and your groups for virtual ESAs are pointing to update-manifests.sco.cisco.com:443.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide