From: Ola Lundqvist (opal_at_debian.org)
Date: Mon 01 Dec 2003 - 07:44:34 GMT
Another problem that occurs (I can not see that it fit this
really) is the following:
Assume that we have access to several networks (using 1+ network interfaces)
from the vserver handler. The vserver handler should have access to
(at least) one, that no other have access to and should have a specific
Each other vserver (or similar) should then have the ability to use
an alternative default gateway. That can be useful sometimes.
It would be nice if I could set the default gateway in the
vserver configuration and that the iproute2 things it properly
set up then.
In this case I think a) below would be a good case. But b can also
Observe that ping often work in similar cases. The real problem is
to use TCP or UDP. That is more tricky.
On Sat, Nov 29, 2003 at 04:26:45PM +0100, Herbert Poetzl wrote:
> 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 220.127.116.11
> 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 18.104.22.168
> PING 22.214.171.124 (126.96.36.199) 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 188.8.131.52
> 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 ...
> Vserver mailing list
-- --------------------- Ola Lundqvist --------------------------- / opal_at_debian.org Annebergsslingan 37 \ | opal_at_lysator.liu.se 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver