[pve-devel] LXC with 2 and more NICs

[Wolfgang Bumiller]

> On February 2, 2017 at 10:03 PM Detlef Bracker <bracker at 1awww.com> wrote:
> I thing so, thats a bug!

No. A misconfiguration.

> A ping from outside to the LXC-containers to all NICs works fine!
> 
> A ping from console via the NICs 2-.... is not possible! So, this can
> been a big problem, when a daemon will send from the NICs 2- ....
> 
> ping 8.8.8.8 -I eth0 works fine
> ping 8.8.8.8 -I eth1 Destination Host Unreachable
> ping 8.8.8.8 -I eth2 Destination Host Unreachable
> ping 8.8.8.8 -I eth3 Destination Host Unreachable

First a general suggestion:
Please use `tcpdump` to see if the packets even make it to their destination
and where the responses actually get lost.

As for what you described: You're not providing enough details to give a
complete analysis of the problem (what are these nics, what are they
connected to, is it from within a container? are all eth* on the same
bridge? Are vlans involved? ...).

However, I'll try to give you a few pointers:

If ping works through eth0 then it is very likely that the ping-*replies*
*always* actually come back through eth0 even if you initiate them via
eth1/2/3.
Depending on how `/bin/ping` uses the interface when you use the `-I`
switch, this may even always fail. However, it could also simply be subject
to `reverse path filtering`:
If reverse path filtering is set to `1` then packets coming from an
interface other than the expected one are considered an error and will
be dropped.
See these sysctl values:
  sysctl net.ipv4.conf.all.rp_filter
  sysctl net.ipv4.conf.eth0.rp_filter
  sysctl net.ipv4.conf.eth1.rp_filter
  sysctl net.ipv4.conf.eth2.rp_filter
  sysctl net.ipv4.conf.eth3.rp_filter
If they are `1`, then try `2`. I strongly discourage the use of `0`.

Then of course it could be a firewall issue, or an issue elsewhere: vlans,
bridge ports, gateways, cables...