-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi list,
I have a weird (?) problem here on a setup running CentOS 5.3 x86_64 (and OpenVZ, and some home-brew L2TP daemons, RIPd, BGPd, etc).
There's a (VE in OpenVZ speak) virtual machine that has two ethernet interfaces, seen as eth0 and eth1, respectively. Those live in VLANs, but it's not important here.
The thing is that on eth1 the default route lives, while on eth0 all traffic comes in.
So, sending a ping to the IP address of eth0 tcpdump shows that the echo request (type 8) packet arrives on the machine. However, the machine does _not_ send an echo reply (type 0) back to the machine that pings eth0, maybe because it would have to emerge from eth1.
One exception (an obvious one) is that IPs on the /29 where eth0 lives on _can_ ping eth0 and receive an answer -- this is because the packets don't have to take 'the default route', which lives on the other interface, eth1.
This seems to me like decent behaviour.
However, I really need eth0 to be able to be pinged from the outside world, it's totally okay for me that eth1 would 'answer' and send the echo replies instead of eth0.
Is there anything I can tweak (via sysctl or whatever)?
TIA,
Timo
On Thu, Oct 1, 2009 at 2:02 PM, Timo Schoeler timo.schoeler@riscworks.netwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi list,
I have a weird (?) problem here on a setup running CentOS 5.3 x86_64 (and OpenVZ, and some home-brew L2TP daemons, RIPd, BGPd, etc).
There's a (VE in OpenVZ speak) virtual machine that has two ethernet interfaces, seen as eth0 and eth1, respectively. Those live in VLANs, but it's not important here.
The thing is that on eth1 the default route lives, while on eth0 all traffic comes in.
So, sending a ping to the IP address of eth0 tcpdump shows that the echo request (type 8) packet arrives on the machine. However, the machine does _not_ send an echo reply (type 0) back to the machine that pings eth0, maybe because it would have to emerge from eth1.
One exception (an obvious one) is that IPs on the /29 where eth0 lives on _can_ ping eth0 and receive an answer -- this is because the packets don't have to take 'the default route', which lives on the other interface, eth1.
This seems to me like decent behaviour.
However, I really need eth0 to be able to be pinged from the outside world, it's totally okay for me that eth1 would 'answer' and send the echo replies instead of eth0.
Is there anything I can tweak (via sysctl or whatever)?
You need a way to tell that packets originating from eth0 destined outside should be routed to eth0. This thread should help:
http://lists.centos.org/pipermail/centos/2009-January/070828.html
Giovanni P. Tirloni tirloni@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Giovanni Tirloni spake: | On Thu, Oct 1, 2009 at 2:02 PM, Timo Schoeler | timo.schoeler@riscworks.netwrote: | |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Hi list, |> |> I have a weird (?) problem here on a setup running CentOS 5.3 x86_64 |> (and OpenVZ, and some home-brew L2TP daemons, RIPd, BGPd, etc). |> |> There's a (VE in OpenVZ speak) virtual machine that has two ethernet |> interfaces, seen as eth0 and eth1, respectively. Those live in VLANs, |> but it's not important here. |> |> The thing is that on eth1 the default route lives, while on eth0 all |> traffic comes in. |> |> So, sending a ping to the IP address of eth0 tcpdump shows that the echo |> request (type 8) packet arrives on the machine. However, the machine |> does _not_ send an echo reply (type 0) back to the machine that pings |> eth0, maybe because it would have to emerge from eth1. |> |> One exception (an obvious one) is that IPs on the /29 where eth0 lives |> on _can_ ping eth0 and receive an answer -- this is because the packets |> don't have to take 'the default route', which lives on the other |> interface, eth1. |> |> This seems to me like decent behaviour. |> |> However, I really need eth0 to be able to be pinged from the outside |> world, it's totally okay for me that eth1 would 'answer' and send the |> echo replies instead of eth0. |> |> Is there anything I can tweak (via sysctl or whatever)? |> | | | You need a way to tell that packets originating from eth0 destined outside | should be routed to eth0. This thread should help: | | http://lists.centos.org/pipermail/centos/2009-January/070828.html | | Giovanni P. Tirloni | tirloni@gmail.com
Thank you very much, Giovanni -- seems exactly to be what I need.
Cheers,
Timo
-
Giovanni Tirloni -
Timo Schoeler