|
On Thu, 20 Jan 2000, Joseph Mack wrote:
> Is ip_forwarding _NOT_ needed for VS-Tun? In the HOWTO I have that it's
Sorry for the delayed response Joe, I've been incredibly busy with Stuff.
Any how, the above is correct, ip_forwarding is NOT needed for VS-Tun.
cf routing from our backup director:
[zathras@curtius sysconfig]$ cat /proc/sys/net/ipv4/ip_forward
/proc/net/ip_masq/vs|sed -e "s/194.83.240.../realserver/g"
0
IP Virtual Server version 0.8.3 (size=65536)
Protocol LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP realserver8:8080 wlc
-> realserver:8080 Tunnel 1000 391 2885
-> realserver:8080 Tunnel 1000 384 3346
-> realserver:8080 Tunnel 1000 383 3288
-> realserver:8080 Tunnel 1000 386 3269
-> realserver:8080 Tunnel 500 196 1482
-> realserver:8080 Tunnel 500 189 1734
-> realserver:8080 Tunnel 500 189 1758
-> realserver:8080 Tunnel 1000 385 3192
-> realserver:8080 Tunnel 1000 384 3162
Snapshot as of now. However it's my feeling that it's more using to leave
IP forwarding switched on since that opens up the realms of NAT/DR for
special cases. The routing table on our second cluster looks something
like this:
[zathras@pepper /]$ /sbin/ipvsadm |sed -e "s/194.83.240.../realserver/g"
IP Virtual Server version 0.8.3 (size=65536)
Protocol LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP realserver0:8080 wlc
-> realserver:8080 Tunnel 900 64 1190
-> realserver:8080 Route 1000 62 1689
-> realserver:8080 Route 1000 59 1938
-> realserver:8080 Route 1000 64 1665
-> realserver:8080 Tunnel 1000 73 1216
Due to the mixture of OS's. The reason for choosing tunneling for the
linux boxes is simply to try and keep them all configured the same way,
wherever they're being load balanced from.
Michael.
--
National & Local Web Cache Support R: G117
Manchester Computing T: 0161 275 7195
University of Manchester F: 0161 275 6040
Manchester UK M13 9PL M: Michael.Sparks@xxxxxxxxxxxxxxx
On Thu, 20 Jan 2000, Joseph Mack wrote:
>
> > > Beware: This also sets the root (logical) loopback into noarp mode! But
> > > it worked for me with LVS-DR v.0.9.2 & FreeBSD 3.2, 3.3 (I made a
> > > mistake, I didn't test FreeBSD 3.1).
> >
> > When I'd been trying it last time, I knew I'd probably missed something
> > very simple and stupid and I had.
> >
> > And realised this time what I had done wrong - I'd rather stupidly
> > forgotten to switch IP forwarding on on the director. (Since we're using
> > tunneling for the other servers this hadn't affected the Linux boxes...)
>
> Is ip_forwarding _NOT_ needed for VS-Tun? In the HOWTO I have that it's
> needed (I knew it was needed in VS-DR so assumed it was needed in VS-Tun
> without thinking about it a lot). If it's not needed is this because at
> least one of the s_addr and d_addr are changed on the packet?
>
>
> HOWTO Sect 8.5 icmp redirects, ip_forwarding
>
> .
> .
>
> ip_forward should be on for VS-DR (and VS-Tun) as the source
> address of the outgoing (towards the realserver) packets is that
> of the client. (This is handled by configure.pl). Ip_forwarding
> is on by default in 2.0.x kernels and off by default in 2.2.x
> kernels. Beware if you are constructing scripts yourself.
>
> > In case it's of use to anyone else, to use FreeBSD boxen as real servers:
>
> I'm putting ratz's stuff into the configure file this week (I hope)
>
> >
> > Tested on FreeBSD 3.2-STABLE & 2.2.5-STABLE.
>
> these are the `uname -r` outputs for the 2 FreeBSD's you tested?
>
> Thanks
> Joe
> --
> Joseph Mack mack@xxxxxxxxxxx
>
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
