cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5299
Views
20
Helpful
2
Replies

Update issues when ESA Virtual replacing C170 Appliance in Cluster Config

Paul Cardelli
Level 1
Level 1

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:

  1. run the clusterconfig on one of my virtuals, 
  2. Remove Virtual from ClusterConfig after config is migrated
  3. Apply CLI fix to point post-cluster config Virtual so it now points to the right update servers
  4. Create new cluster with the now fully Updating Virtual-Uno ESA
  5. Join Remaining virtuals to the newly created cluster and phase out the old physical cluster?

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.

 

 

2 Replies 2

Paul Cardelli
Level 1
Level 1

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

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.