On Thu, 25 Apr 2002, Clifton Royston wrote:
:: > :: > 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. ;)
:: > ::
:: >
:: > It does.
::
:: Are you talking about DSR or something else? The problem I am
Yes. What you are proposing would require him to put his dns servers
across his serveriron from his mail servers, etc.. DSR allows him to keep
all his servers on a single lan, and hit his virtuals from everything
on that lan without having to traverse the serveriron. This is how he has
laid out his network, there is no reason for him to re-design it - it is a
perfectly valid way of doing things. The only real functionality that you
loose is proper connection based load balancing (it works, but can get
somewhat invalid results due to the fact that the serveriron won't see
resets). You also may loose some syn-flood protection, although i haven't
tested this in quite a while, so don't quote me.
To the original poster, you might want to turn off ident lookups - i seem
to remember a problem with auth lookups being sourced from the loopback
and not having a valid return path through the serverIron. In theory, this
could cause your sendmail boxes to hang on every incoming smtp connect.
-jba
:: describing - in which I saw similar problems to his with a similar
:: configuration to his - is a *completely* separate issue from DSR. In
:: that instance, the initial connection never got properly established to
:: the server in the first place, never mind about DSR. If you look at
:: the example network diagrams on configuring SLB in their manual, you
:: will note that they *all* show the first type of diagram I showed
:: above: real servers directly connected to ServerIron ports.
::
:: Are you actually running with the network configuration he illustrated,
:: or are you only speaking from theory? Unless they've changed it in the
:: last year or so, I believe it does not work in practice. (Well, I
:: think it *might* work if you configured all the servers as "remote"
:: servers, but then unless they've enhanced it recently, you end up
:: losing other important functionality, like dead server detection.)
::
:: I'd be delighted to be proved wrong, as it's been a real pain to have
:: to limit their use this way.
::
:: > Use DSR. Don't believe the hype.
:: >
:: > You'll loose some functionality that requires the serveriron to see the
:: > entire flow, but overall DSR is a winner for its performance and
:: > flexibility.
::
:: That's not the issue. DSR does roughly double the throughput, if you
:: really need the high throughput. The issue is that he has a
:: configuration that does not work, and he needs to resolve why it
:: doesn't work.
::
:: The first step in troubleshooting should always be to reduce it to a
:: simpler situation, which is why I recommended taking out DSR while
:: troubleshooting, even though I've pointed to a different cause for the
:: problem.
::
:: -- Clifton
::
::
--__ [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:05 EDT