|
> > Yesterday we stumbled on the problem with certain versions of
> > 'ifconfig' not displaying the aliased interfaces (eth0:110)
> > seperate from eth0.
>
> "ratz wrote:"
> Please read [1] to understand why things like that happen. In short:
> ifconfig and route are a deprecated tools and are not 100% compatible
> with iproute2 if mixed.
>
[1]http://marc.theaimsgroup.com/?l=linux-virtual-server&m=10032525291591
9&w=2
I'm not using iproute2. I'm using ifconfig/route (via Joe's configure
script)
>
> > 1) In setup_director_vip() the following fails. I think the $ROUTE
> > command has a problem with the aliased device. Changing to
> > $SHORT_DIRECTOR_VIP_DEVICE seems to have worked. $ROUTE add -host
> > $VIP dev $DIRECTOR_VIP_DEVICE
>
> "ratz wrote:"
> Do you intend to route over a 'alias'd interface' IP (secondary IP)?
#
# ________
# | |
# | client |
# |________|
# CIP=eth0 10.139.60.1
# |
# |
# VIP=eth1:121 10.139.60.121/22
# __________
# | |
# | director |
# |__________|
# DIP=eth0:1 192.168.1.1
# |
# |
# |
# --------------------------------------------------
# | | | |
# | | | |
# RIP1=eth0 RIP2=eth0 RIP3=eth0 RIP4=eth0
# 192.168.1.2 192.168.1.3 192.168.1.4 192.168.1.5
# ______________ ______________ ___________ ___________
# | | | | | | | |
# | realserver1 | | realserver2 | | rs3 | | rs4 |
# |______________| |______________| |___________| |___________|
I'm using the LVSCONF_FORMAT=1.1. The lvs_nat.conf template suggests an
alias for the VIP and the DIP. In this case, I don't think they are
'secondary', but I assumed supplying the alias wouldn't be a problem.
From lvs_nat.conf:
#To help avoid namespace collisions with other VIPs, I set alias=last
number of VIP (here 110).
VIP=eth1:121 penguin1 255.255.252.0 10.139.63.255
#DIP line format - device[:alias] IP network netmask broadcast
DIP=eth0:1 dip 192.168.1.0 255.255.255.0 192.168.1.255
>
> > 2) As mentioned in a previous thread, I am losing my
> default gateway
> > on the director. Looking at the rc.lvs_nat script that was
> > generated, the default gateway is removed but never put back in.
> > Adding "DEFAULT_GW=<my gateway IP>" to the script works.
>
> "Joseph Mack wrote:"
> this is supposed to happen. I posted something about this on friday.
> see
>
>
http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-13.html#ss
13.8
I'm new to this, so please bare with me. I am using VS-NAT, so I assume
all traffic comes back through my director. Without the default GW I
don't get any traffic back to my clients. I think friday's discussion
was for VS-TUN??? In install_director_gw() this code section is
commented out:
#Aug 2001, used to have logic here to detect whether to set a
default gw for the director
#the logic is now in from_director_check_target_of_server_gw
#if [ $LVS_TYPE = "vs-nat" ]
#then
# #note blank at the end of the IP
# DEFAULT_GW=$DIRECTOR_GW
# $ECHO "setting director default gw to $DIRECTOR_GW for
$LVS_TYPE LVS"
# #echo "Setting director default gw. "
# install_default_gw
# $ECHO " "
#else
# #don't install a default gw for VS-DR, VS-Tun.
# #Just remove old ones.
# $ECHO "no director default gw installed for $LVS_TYPE
LVS"
# DEFAULT_GW=""
# install_default_gw
#fi
but in from_director_check_target_of_server_gw() I don't see the
DEFAULT_GW being set (only the message indicating "default gw
192.168.1.1 for the vs-nat servers is on director, good"). Thats why I
ended up just setting my DEFAULT_GW in the rc.lvs_nat. Since DEFAULT_GW
is not set, install_default_gw() will delete the default gateway (that I
had set before running the rc.lvs_nat), but will not re-install it:
From log file...
"deleting current default gw 10.139.60.1"
"not installing a default gw for LVS_TYPE vs-nat"
...
>
> > 3) Finally, when I initiate a connection from my realserver out to
> > the internet (because my service requires a connection initiated by
> > the realserver), the packets are routed throught the director, but
> > are not NATed. The clients are seeing packets with the RIP1
> > address.
>
> "ratz wrote:"
> Care to show an output of ipvsadm -Ln?
>
IP Virtual Server version 0.8.2 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.139.60.121:4300 rr
-> 192.168.1.5:4300 Masq 1 0 3
-> 192.168.1.4:4300 Masq 1 0 3
-> 192.168.1.3:4300 Masq 1 0 3
-> 192.168.1.2:4300 Masq 1 0 3
> "Joseph Mack wrote:"
> I assume this is a consequence of the previous errors. Let's fix them
first.
Thats what I was thinking too!
Thanks,
-Todd
smime.p7s
Description: S/MIME cryptographic signature
|
