<div dir="ltr"><div class="gmail_extra"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px">We had a similar problem recently.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Apparently the difference is in the host machine:</div><div style="font-size:12.8px">-ubuntu 14 <b>has</b> the bridge module charged in the kernel with </div><div style="font-size:12.8px"><div style="font-size:12.8px">by default (check with sysctl -a)</div><div style="font-size:12.8px">net.bridge.bridge-nf-call-arptables = 1</div><div style="font-size:12.8px">net.bridge.bridge-nf-call-ip6tables = 1</div><div style="font-size:12.8px">net.bridge.bridge-nf-call-iptables = 1</div><div style="font-size:12.8px"><br></div></div><div style="font-size:12.8px">in this case we used to forward the traffic "from" and "to" the bridges where we had LXC attached and to masq the ips when needed.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">-ubuntu 16<b> has not</b> (even if you create bridges and set iptables to forward the bridges traffic) unless you add the following rule: </div><div><span style="font-size:12.8px">(check with sysctl -a|grep bridges)</span><br></div><div style="font-size:12.8px"><span style="font-size:12.8px"><b>-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT</b></span></div><div><div><span style="font-size:12.8px">(check again with sysctl -a|grep bridges)</span><br></div><div style="font-size:12.8px"><br></div></div><div style="font-size:12.8px">this way you'll have the same behaviour as with the Ubuntu 14 (well...more or less, you may need to trim a bit the forwarding table)</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Let me know if this helps</div><div style="font-size:12.8px">ciao</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div><div><span style="font-size:12.8px">Dr. Alex Barchiesi</span></div><div><span style="font-size:12.8px">____________________________________</span></div><div><span style="font-size:12.8px">Senior cloud architect </span></div><div><span style="font-size:12.8px">Art -Science relationships responsible</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">GARR CSD department </span></div><div><span style="font-size:12.8px">linkedin: alex barchiesi</span><br></div><div><span style="font-size:12.8px">_____________________________________</span></div><div><span style="font-size:12.8px">I started with nothing and I still have most of it.</span></div><div style="font-size:12.8px"><br></div></div><div style="font-size:12.8px"><br></div></div></div></div></div></div></div><div class="gmail_quote">On Tue, Jul 19, 2016 at 2:00 PM, <span dir="ltr"><<a href="mailto:lxc-users-request@lists.linuxcontainers.org" target="_blank">lxc-users-request@lists.linuxcontainers.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br>---------- Forwarded message ----------<br>From: Ruzsinszky Attila <<a href="mailto:ruzsinszky.attila@gmail.com" target="_blank">ruzsinszky.attila@gmail.com</a>><br>To: <a href="mailto:lxc-users@lists.linuxcontainers.org" target="_blank">lxc-users@lists.linuxcontainers.org</a><br>Cc: <br>Date: Tue, 19 Jul 2016 07:54:34 +0200<br>Subject: [lxc-users] LXC networking stop working between containers and real network<br><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>There is an Ubuntu 14.04 64 bit up to date host.<br></div>LXC version is: 2.0.3 (from backport packages)<br></div>OpenvSwitch: 2.0.2.<br><br></div>Container1: Ubuntu 14.04<br></div>Container2: Ubuntu 16.04 (both of them was installed from root.fs.zx, because lxc-create doesn't work with auth. Squid proxy)<br><br></div>Both containers are working perfectly in "standalone" mode.<br></div>I use lxcbr0 as a bridge between the containers. There is dnsmasq for DHCP and it is working, because containers get IP address (from <a href="http://10.0.3.0/24" target="_blank">10.0.3.0/24</a> range).<br></div>There is an OVS bridge: vbr0 and its port is lxcbr0 on the host. The real Ethernet interface is: eth0 which is connected to the real network. There is a mgmtlxc0 virt. management interface which IP is: <a href="http://10.0.3.2/24" target="_blank">10.0.3.2/24</a>. I can ping every machine in the <a href="http://10.0.3.0/24" target="_blank">10.0.3.0/24</a> range.<br></div>The MAC addresses of the containers are different. I checked them.<br></div><div>mgmtlxc0 and the lxcbr0 are tagged for VLAN (tag=800 in OVS config)<br></div><div><br></div><div>I want to MASQUERADE the lxc-net to the real network:<br>Chain POSTROUTING (policy ACCEPT 54626 packets, 5252K bytes)<br> pkts bytes target prot opt in out source destination <br> 246 20520 MASQUERADE all -- * * <a href="http://10.0.3.0/24" target="_blank">10.0.3.0/24</a> !<a href="http://10.0.3.0/24" target="_blank">10.0.3.0/24</a><br><br></div><div>Routing table:<br>root@fcubi:~# route<br>Kernel IP routing table<br>Destination Gateway Genmask Flags Metric Ref Use Iface<br>default real_router 0.0.0.0 UG 0 0 0 eth0<br>LXCnet * 255.255.255.0 U 0 0 0 mgmtlxc0<br>FCnet * 255.255.255.0 U 1 0 0 eth0<br></div><div><br></div>The problem is:<br></div>I try to ping from container1 (lub4) to a host on the real network. It is working.<br></div>I try to ping from container2 (lub5) to the same host and it is not working! The DNS resolving is OK, but no answer from the real host.<br><br></div>I checked the traffic on eth0 on lub4 or 5 (inside the containers). I can see the ICMP echo REQ packets.<br></div>They are arrived to the host's lxcbr0 interface. I think it is good.<br></div>I checked the hosts's mgmtlxc0 interface which is the routing interface on IP level. I can see the REQ packets.<br></div>ip4_forwarding is enabled (=1).<br></div>The next interface is eth0 and no traffic from containers on it! I filtered for ICMP and no REQ! So the host "filter out" (or not routing) my MASQUed ICMP packets.<br></div>I think it is not a MASQ problem, because without MASQUERADING I had to see the outgoing REQ packets with wrong source IP (10.0.3.x) and of course there won't be any answer because the real host knows nothing about routing to 10.0.3.0 lxcnet. But no any outgoing packets.<br></div><div>I tried to remove the all iptables rules except MASQ and nothing was changed.<br><br></div><div>If I ping between lub4 and 5 it is working (virtual) when the real not.<br></div><div><br></div>If I restart the containers one by one and I change the ping test (1st is lub5 and the 2nd is lub4) the 2nd won't ping so not depend ont the containers OS version.<br><br></div><div>I think the problem maybe in MASQ or routing between mgmtlxc0 and eth0. netstat-nat doesn't work and I don't know why.<br></div>Do you have any clue?<br><br></div>I've got another host which is Fedora 23 64 bit (OVS 2.5) with 3 U14.04 containers and it seems working.<br><br></div>I'll do some more test. For example making a new U14.04 container because on F23 the container's versions are the same.<br>LXD was installed but not used or configured.<br><br></div>TIA,<br></div>Ruzsi<br></div>
</blockquote></div><br></div></div>