Hello Herbert,
thanks for your reply, we managed to track down things a bit further:
I wrote:
> The ifconfig call inside /sbin/vserver introduces another route on eth1:
>
> master22:/etc/vservers# ip route sh
> 137.248.9.0/27 dev eth0��proto�kernel��scope�link��src�137.248.9.13
[other routes]
> 4. Now I adjust the routing tables:
> master22:/etc/vservers# ip route del 137.248.9.0/27 dev eth0
> master22:/etc/vservers# ip route add 137.248.9.0/27 dev eth0 src 137.248.9.13
> table 2
> master22:/etc/vservers# ip route add default dev eth0 via 137.248.9.30 src
> 137.248.9.13 table 2
> RTNETLINK answers: Network is unreachable
There seems to be an issue with the additional route introduced by ifconfig.
If I simply leave it in place for the moment, build the second table, and
remove it _afterwards_, things seem to be fine.
Looks weird to me, though ...
BTW: I learned from your examples that chbind is useful for testing such
network stuff, but I also learned that ping happily breaks out of its IP jail:
master22:~# chbind --ip 137.248.9.13 ping -R -c 1 137.248.3.34
ipv4root is now 137.248.9.13
PING 137.248.3.34 (137.248.3.34) 56(124) bytes of data.
64 bytes from 137.248.3.34: icmp_seq=1 ttl=254 time=1.35 ms
NOP
RR: 192.168.1.18
137.248.3.250
137.248.3.34
137.248.1.126
192.168.1.18
--- 137.248.3.34 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.359/1.359/1.359/0.000 ms
I verified this on the target machine (a solaris box).
So raw sockets seem to be a different story altogether.
Greetz, Martin
--
Dr. Martin Pauly Fax: 49-6421-28-26994
HRZ Univ. Marburg Phone: 49-6421-28-23527
Hans-Meerwein-Str. E-Mail: [EMAIL PROTECTED]
D-35032 Marburg
_______________________________________________
Vserver mailing list
[email protected]
http://list.linux-vserver.org/mailman/listinfo/vserver
