|
On Fri, Aug 30, 2002 at 03:54:14PM -0400, Joseph Mack wrote:
:"Jonathan D. Proulx" wrote:
:>
:> I can get telnet to work but not http (Apache/1.3.26 (Unix) Debian
:> GNU/Linux). Attempts to connect to http://lvs-test result in a network
:> error (rst after the initial ack).
:
:> I have set the listen address in the httpd.conf on the realservers.
:
:is apache listening to the VIP and _not_ to the RIP?
That is correct listen vip:80, netstat and external portscaning
confirm port 80 is open on the VIP and _not_ the RIP
:> running the resultant rc.lvs removes the default route on the director
:> so that no connections off the local /24 subnet are possible,
:
:it's a design feature
:
:http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-13.html#ss13.6
This asymetric routing is what I expected, and why I'm puzzled by the
director's default routing having any affect on the client. But I'm
watching it now, if I remove the default route I can no longer telnet
to the LVS (the director is _not_ running telnet, only the
realservers).
:you can add the route back if you like, but it would be more secure to
:put a separate IP on the outside of the director (possibly on the same NIC as
:the VIP) and to connect from that.
I could definatly learn more about iproute2, as I only installed it on
these systems because LVS seems to be moving toward this, but:
[jon@director lvs]$ ip route
128.52.37.21 dev eth0 scope link src 128.52.37.21
128.52.37.0/24 dev eth0 proto kernel scope link src 128.52.37.173
default via 128.52.37.10 dev eth0
[jon@realserver0 jon]$ ip route
128.52.37.21 dev lo scope link src 128.52.37.21
128.52.37.0/24 dev eth0 proto kernel scope link src 128.52.37.4
default via 128.52.37.10 dev eth0
[jon@realserver1 jon]$ ip route
128.52.37.21 dev lo scope link src 128.52.37.21
128.52.37.0/24 dev eth0 proto kernel scope link src 128.52.37.253
default via 128.52.37.10 dev eth0
note 128.52.37.21 is VIP, 128.52.37.173 is DIP. This seems to be what
I expect
:
:> this
:
:adding the default route or not having it?
not having the default route (only for systems off the /24 subnet)
:> also seem to cut off access to the realservers which I don't fully
:> understand.
:
:> So initially all connections just hang till timeout.
:>
:> Adding a default route on the director allows telnet through to the
:> realservers
:
:via the LVS or directly?
via the LVS, telnet to VIP alternately connects to realserver1 and realserver2
:
:> and the above mentioned RST problem on http. Without
:> mucking with routing a client on the same /24 gets the same result.
:
:same as what?
Sorry for the confusion:
if the client is on 128.52.37/24 the default route or lack there of on
the director is irrelevent (as it retains a route to its own /24)
if the clent is not on 128.52.37/24 and the director does not have a
default route all attemted connectons to the LVS will hang untill time
out.
In short the routing issue and the HTTP issue seem unrelated. If the
director can route to the client telnet wins and http looses with
initial connection followed by rst. If the director cannot route to
the client the client gets nothing back.
Thanks,
-Jon
|
