I'm wondering if anyone has any experience with setting up a redundant Blocker setup. Our current setup (Blocker as primary MX and a fallback MX offsite) is redundant when it comes to not losing email. My main concern now is what will happen if the Blocker fails alltogether. Granted no email will be lost, but no email will be delivered either unless there is a manual intervention (switching fallback MX to deliver mail directly instead of via the Blocker).
Any hints or tips as to how to setup a redundant Blocker configuration?
the blocker has been designed from the outset to not have a centralised policy management feature. To setup a redundant CSVB design you will need to to download the xml config file from the primary device and upload this onto a secondary device.
The entire configuration is stored within the xml file and be downloaded via ftp from the /config folder.
To save the current config you can use the cli command 'saveconfig' or in the GUI select the 'Systems Administration -> Configuration file' option.
Then you will need to upload the xml to your secondary CSVB /config folder via ftp.
Finally load the current xml file into production using the CLI command 'loadconfig' or again use the GUI Systems Administration -> Configuration file' option.
A few notes:-
- both csvb's need to be on the same version & build as the xml file changes between version & builds
- using the CLI enables a script to be writtn to automate this process such it just becomes a script you can run on a scheduled basis as other customers do today
Going through this thread I understand that a redundant configuration of 2 Spam Blockers can be done.
Can you please explain a little more what are the possible options? Active/Active? Active/Standby? Is the fallback done automatically to the 2nd device?
I assume the 2 devices need to have exactly the same user license... correct?
And last but not least, execpt for the structured explanation on how to configure redundancy mentioned previously in this thread, can you direct me to a document (configuration guide of some kind) where the whole process of configuring the redundant architecture is explained in details (preferably an official Cisco guide...), if one exists.
Thanks for your support.
you can run them as active/active or active/passive....as you buy a CSVB per box the design is up to you as to what suits best. Most customers prefer to run active/passive as this is simple and means one primary place to search and report from as the secondary csvb should do nothing apart from attrack spam if the primary csvb is doing it's job well.
Fallback from primary to secondary would be done via mx records. MX records have costing built-in i.e. a mail can try primary first, then secondary, tertiary for example. Here's an example below:
MX=mail.aircomm.co.uk PREF=30 TTL=6h
MX=spamgizmo.flirble.org PREF=20 TTL=6h
MX=dm.gbnet.net PREF=10 TTL=6h
MX works from lowest costing to highest - in the example below it go from 10 to 20 to 30 to attempt delivery.
The devices will be needed to be licenced for the same user count - as either could be the only perimiter mail server in event of failure. However an Cisco IronPort is another option as the cost of a secondary unit is 50% LESS than a primary box - this may come up with a similar price but with more flexibility...worth considering financially before going down a dual CSVB design in my opinion.
No official guide on setting up as yet - this would be a good one for us to write up i think.
The set of commands to be added to a scrip or manual process would be to :
1. logon to the primary CSVB
2. Saveconfig to save the xml config file the ftp folder on the csvb
3. Copy the xml file from cscb #1 to csvb #2 ftp folder (assuming it's online and on the same version & build)
4. logon to the secondary CSVB
5. Loadconfig to save the config to the new device.
Alos i've attached a more advanced perl script that copies a config file to an appliance then loadconfigs it. It has a fair amount of error checking with distinct return codes for different errors which may be more advanced and may need a few minro changes to meet your needs.
It's been a while since I posted this thread. In the mean time we've purchased a second Blocker for redundancy and have it running in an Active/Active setup now. The way we balance email traffic is as described above, but with a small change:
MX=blocker1.example.com PREF=10 TTL=6h
MX=blocker2.example.com PREF=10 TTL=6h
MX=fallback.example.com PREF=100 TTL=6h
I've looked through your perl script, but I'm missing a few critical points. It's nessesary to edit the XML file before commiting it on the second blocker, otherwise the second blocker will attempt to boot with the IP and MAC address of the first blocker. Look for these strings in the XML file: