Messaging Gateway

 View Only
  • 1.  DR & Layered design for SBG 8.02

    Posted Aug 10, 2009 07:11 PM
    I currently have 8 SBG scanners located in 4 DMZ zones.  Each DMZ (2 Scanners) is managed by a control center.  These are old 8200 boxes.  Total of 30 million mail / day inbound, 2 million outbound.  About to upgrade to some # of 8380's.

    City 1   Data Center 1  --  2 scanners in DMZ, 1 control center/scanner,
    City 1   Data Center 2  --  2 scanners in DMZ, 1 control center/scanner,
    City 2   Data Center 1  --  2 scanners in DMZ, 1 control center/scanner,
    City 2   Data Center 2  --  2 scanners in DMZ, 1 control center/scanner,

    the control/scanner on the inside of the network also acts as a smart host for internal senders (many Unix boxes) and then relays out to the DMZ for outbound flow.  The inside senders talk to the outbound interface.

    Mail volumn

    I'd like to reduce the number of control centers so I'm not having to enter config changes into 4 control centers..
    I'd also like to separate DMZ spam/virus/policy layer from the inside "smart host" layer.

    I also need to support 4-6 domains (not just subdomains).  I've been told that each control center can support 4 scanners (including any local scanner on the CC).

    I'm considering the following:

    1.  City 1 Data Center 1 
             Inside:  Control Center for all DMZ boxes in city 1 (4 scanner)
             Inside:  Scanner 1 for smarthost/policy layer
             DMZ : 2 scanners

    2.  City 1, data Center 2
             Inside:  Control Center for Smart hosts,  Scanner 2 for smart hosts
             DMZ: 2 scanners

    Ditto for city 2.

    I have  a concern about rebuilding a control center if I loose a building.  The replacement scanner would be in new address space, and recovery from backup recovers IP addressing.
    I suppose I'd restore then use the serial console to change IP addressing.

    Thoughts?
                                           



  • 2.  RE: DR & Layered design for SBG 8.02

    Posted Aug 11, 2009 05:20 PM

    So my only concern would be the amount of ports you would have to open between DMZ zones. In order to have the scanners communicate with the <st1:place w:st="on"><st1:placename w:st="on">Control</st1:placename> <st1:placetype w:st="on">Center</st1:placetype></st1:place> there are several ports needed to be open. All of these can be found in the admin guide. 

    Also if you are going to be having any scanners internally, you will have to open ports here as well. Which somewhat defeats the purpose of the DMZ depending on how you do this.

    Also, depending on how much mail flow is going through the server, whether or not you are quarantining spam / suspect spam / unscannables / etc. , how much logging and reporting you are doing, there isn't really a stated "limit" to how many scanners you can have attached to one <st1:place w:st="on"><st1:placename w:st="on">Control</st1:placename> <st1:placetype w:st="on">Center</st1:placetype></st1:place>. A general rule would be; The more scanners you have attached, the less you want the <st1:place w:st="on"><st1:placename w:st="on">Control</st1:placename> <st1:placetype w:st="on">Center</st1:placetype></st1:place> doing.

    If you are already in touch with sales, they might have a better idea on all of this, so if you have already had that assessed I'm sure you are ok there.

    Hope this helps.
    Tom



  • 3.  RE: DR & Layered design for SBG 8.02

    Posted Aug 11, 2009 05:31 PM
    The boxes already exist in the DMZ so I already have rule sets, changing CC's is just an IP address change.
    for loging, we have an OC3 between sites within the each city.

    RE scanner limit. I was told the 4 scanner limit in Case 281-718-712
        "He asked how many scanners can be controlled by 1 BCC
          --I advised 4 would be the most he would want to have under 1 BCC"

    The internal scanner infrastructure would only talk to the DMZ boxes for outbound e-mails (I'm using port 587 on the DMZ outbound i/f). and the DMZ boxes talk to the inside box on port 25 for mail for any local domains.

    As I said, one part of this is keeping compliance policies off the DMZ boxes for performance.


  • 4.  RE: DR & Layered design for SBG 8.02

    Posted Aug 11, 2009 06:09 PM
    So from what you are saying, it sounds like this should work. A little complicated, but I'm sure you don't have the least complicated setup. :)

    For the scanner limit, we are on the same page. David speaks more of a "reasonable" limit on scanners per CC. He may also have had a better idea from talking to you on how much was going on with the scanners and Control Center to be able to make that reccommendation. But when it comes to policy, this is treated on a case by case basis. So we don't "technically" have a "limit". (Sorry for my gross overuse of quotes.)

    Did you have any other concerns going in to this? As always, if you have any problems along the way or questions, feel free to post here or give us a call. We are more than happy to help!

    Thanks!
    Tom


  • 5.  RE: DR & Layered design for SBG 8.02

    Posted Aug 12, 2009 12:03 PM
    Sound like the 4 per CC is a "reasonable capacity" decision and not a hard coded limit in the CC.  I'm really trying to reduce the # of control centers from the 2 scanner / CC to something more resonable.  My city admins are pushing back about only having a single CC for thier 4 scanners in the city.

    I'm testing DR recovery time (restore backup to new box @ different IP adressing) now (I know, not supported), but I think the Tech & I have a workable solution.



  • 6.  RE: DR & Layered design for SBG 8.02

    Posted Aug 12, 2009 02:13 PM
    Only suggestion I also might have, if you are going to repurpose those boxes to be handling more scanners, if you can get away having them as CC only boxes they will do better. 4 scanners to a CC only box I agree sounds reasonable. 


  • 7.  RE: DR & Layered design for SBG 8.02
    Best Answer

    Posted Aug 14, 2009 11:46 AM
    Site A to the left, site B to the right.  CS Layer 3 is a Cisco Content switch for load balance / DRimagebrowser image