On Thu, Apr 25, 2002 at 09:36:53AM -0400, Dale Hege wrote:
>
> Thanks for the info. Here is a snipet of the config for my mailservers
>
> server port 25
> tcp
>
> server port 110
> tcp
>
> server port 143
> tcp
>
> server real m0 z.z.z.z
> port pop3
> port imap4
> port smtp
> !
> server real m1 y.y.y.y
> port pop3
> port imap4
> port smtp
> !
> server real m2 x.x.x.x
> port pop3
> port imap4
> port smtp
> !
> server virtual m f.f.f.f
> port smtp
> port smtp dsr
> port imap4
> port imap4 dsr
> port pop3
> port pop3 dsr
> bind smtp 1 smtp m2 smtp m3 smtp
> bind imap4 m0 imap4 m1 imap4 m2 imap4
> bind pop3 m0 pop3 m1 pop3 m2 pop3
This all looks correct, though like I say I'd skip the DSR initially
and let the ServerIrons rewrite the packets both ways. I think the
problem is below.
> Our setup looks like this.
>
> Clients
> |
> -----------
> | Router |
> -----------
> |
> ----------- -------------
> Servers/Clients-| Switch |-| Foundry A |-|
> ----------- ------------- | HSRP
> Servers/Clients-| Switch |-| Foundry B |-|
> ----------- -------------
> Servers/Clients-| Switch |
> -----------
>
> I'm currently running 07.3.04T12
This is exactly how I first tried to set things up several years ago.
In my experience, unless they have drastically changed the design, the
physical topology you are showing here won't work.
The logic they explained to me is that because the ServerIrons function
as a switch not a router, they will never ever forward an Ethernet
packet back *out* the port it came *in* on, because that is verboten
for Ethernet switches. This applies even if it's rewriting the packet
for a virtual server, even if it should be delivering it to a separate
VLAN, etc. IMHO this is a design error but it's possible to live with.
To make this work, you need to put the servers on a different side of
the Foundry switch from the clients, like this:
m0 m1 m2 m
Servers - [Foundry A] - [Switch] - Clients
| HSRP [Switch] - Clients
Servers - [Foundry B] - [Switch] - Clients
and you need to have each server appear on virtual servers only on the
Foundry it's actually connected to (which is how we do it)
OR you need to do this:
Servers - [New switch] - [Foundry A] - [Switch] - Clients
| (trunks)X [Switch] - Clients
Servers - [New switch] - [Foundry B] - [Switch] - Clients
in which case both ServerIrons could reach any server without violating
the constraint above. Note that you need both ServerIrons connected to
both switches on the left, and you need to be careful about IEEE
spanning tree blocking certain trunks in this case, if you have it
turned on (which you should in a production network.) Let the HSRP
"heartbeat" operate over the trunks to the other switches, not over a
separate trunk between the two.
We've occasionally messed this rule up (e.g. once we made the *backup*
virtual server for mail include a shell server which could send to
mail) and when we did, we found TCP connections from that server
started freezing and as a result processes started stacking up like you
describe.
> Again, thanks for the help..
De nada, hope it helps. Once you get it set up, it works great, and it
has certainly made our life easier with server maintenances, etc.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- cliftonr@lava.net
"What do we need to make our world come alive?
What does it take to make us sing?
While we're waiting for the next one to arrive..." - Sisters of Mercy
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:05 EDT