From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Sat 29 Nov 2003 - 15:26:45 GMT
Hi Folks!
did some iproute2 testing with vserver, and
discovered that some setups will not do
what you might expect (I guess this will
explain some questions on the mailing list
regarding routing with more than one gateway)
for the following examples I assume that no
network configuration has been done, so you
might need to adjust for your setup:
scenario: two networks 192.168.0.0/24 and
10.0.0.0/16 with default gateways 192.168.0.1
and 10.0.0.1 (our host can use .2 and .3)
# ifconfig eth0 192.168.0.2
# ip route add 192.168.0.0/24 dev eth0 table 100
# ip route add default via 192.168.0.1 dev eth0 table 100
# ip rule add from 192.168.0.0/24 table 100
basically this configures routing for the first
network, which is only used, if the packet
originated from 192.168.0.0/24 ...
reaching the gateway:
# ping -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1) from 192.168.0.2 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=4.610 msec
1 packets transmitted, 1 packets received, 0% packet loss
our own address:
# ping -c 1 192.168.0.2
connect: Invalid argument
this might be unexpected, but can easily be
explained and solved ... to ping the host,
we need a local loopback device, hence ..
# ifconfig lo 127.0.0.1
will solve this issue.
something on the net:
# ping -c 1 128.130.2.3
connect: Network is unreachable
why 'Network is unreachable' you might ask?
simple because the source address is 0.0.0.0
and we did not specify a default
and now with vserver:
# chbind --ip 192.168.0.2 ping -c 2 128.130.2.3
PING 128.130.2.3 (128.130.2.3) from 192.168.0.2 : 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=12.320 msec
...
to our surprise, this is able to reach the
destination, and more surprisingly ...
# chbind --ip 192.168.0.2 --ip 192.168.0.3 ping -c 2 128.130.2.3
connect: Network is unreachable
will fail, as the 'original' attempt did.
what happened, is it a bug? can we use that?
basically, it isn't a bug, but it definitely
is unexpected behaviour ... the explanation
lies in the source, and the way ping works ...
ping first creates two socket()s one for ICMP
(a raw socket) and one for IP (UDP), to send
and receive the the packets ... the latter is
connect()ed with src=0.0.0.0 and the dest.
address used in the ping, which explains the
'Network is unreachable' cases, but not the
success of chbind/ping with one ip ...
the current implementation of connect, tries
to be 'smart' and replaces the 0.0.0.0 with
the source address configured for the vserver,
if and only if it has only one ip assigned ...
why this long explanation:
I think, we should change/adapt this behaviour
as it will inevitably lead to some problems
if you want to use more than one gateway, and
connect() from inside the vserver to somewhere
outside the local net ...
# ifconfig eth0:1 10.0.0.2
# ip route add 10.0.0.0/16 dev eth0 table 101
# ip route add default via 10.0.0.1 dev eth0 table 101
# ip rule add from 10.0.0.0/16 table 101
will allow you to serve requests from outside
the server, reaching either 10.0.0.2 or
192.168.0.2 via the configured gateways but
you won't be able to ssh/telnet/ftp from a
vserver started with two or more IPs ...
what I would suggest:
Basically I see two options, to solve this
without too much confusion and/or magic
a) we 'define' that the first IP assigned
to a vserver, is the one to be used for
'outgoing' connects, regardless of the
routing setup (or at least as fallback,
if using 0.0.0.0 fails)
b) we add a 'source' address to the vserver
config, which by default, is 0.0.0.0 and
can be assigned some other ip (probably
restricted to IPs from the config array)
please let me know what you think, and which
direction you would prefer ...
TIA,
Herbert
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver