[pve-devel] LXC with 2 and more NICs

Michael Rasmussen mir at datanom.net
Fri Feb 3 10:04:15 CET 2017


Ping replies will always return via the default route. 

On February 3, 2017 9:55:07 AM GMT+01:00, Wolfgang Bumiller <w.bumiller at proxmox.com> wrote:
>> 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...
>
>_______________________________________________
>pve-devel mailing list
>pve-devel at pve.proxmox.com
>http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


More information about the pve-devel mailing list