On Thu, 25 Apr 2002, Clifton Royston wrote:
> 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.
Hmm, these days they claim it works. ;)
>
> 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.
In these 2 situations can the servers talk to other VIPs? For example,
mailservers user lots of dns and I have a dns VIP can I point the
mailservers m0 m1 m2 dns to the VIP?
>
> 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.
Hmmm. :)
>
> > Again, thanks for the help..
I've been chatting with foundry and they are looking at my setup now.
We'll see. If they don't "fix" it I'll switch to one of the methods above.
(Just been dreading rearranging the ether ports as I havn't been good
about keeping track of them. ;)
-Dale
>
> 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