<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 29, 2015 at 10:40 PM, Peter Steele <span dir="ltr"><<a href="mailto:pwsteele@gmail.com" target="_blank">pwsteele@gmail.com</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"><span class="">On 08/29/2015 07:29 AM, Mark Constable 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">
On 29/08/15 23:54, Peter Steele 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">
For example, I see references to the file /etc/network/interfaces. Is this an<br>
 LXC thing or is this a standard file in Ubuntu networking?<br>
</blockquote>
<br>
It's a standard pre-systemd debian/ubuntu network config file.<br>
</blockquote>
<br></span>
That's what I was beginning to suspect since creating this in my CentOS environment seemed to have no effect on LXC at all. Knowing this will help me filter out examples that talk about creating these files.<br>
<br>
Do you suppose it's possible that Canonical LXC isn't entirely compatible with CentOS?<div class=""><div class="h5"><br>
<br></div></div></blockquote><div><br></div><div><br></div><div>Actually there's no such thing as "canonical lxc".</div><div><br></div><div>While lxc's main developers are currently from canonical, the lxc project itself isn't really tied to a specific distro. For example, since lxc-1.1.0 the bundled init script should function similarly on all distros, with lxcbr0 (including dnsmasq) running by default.</div><div><br></div><div>The main advantage of ubuntu compared to other distros w.r.t lxc that I can see is that:</div><div>- better apparmor integration, so (among others) it should be relatively safer to run privileged container under ubuntu host</div><div>- better container/guest systemd support, where an ubuntu vivid/wily guest should be able to run as privileged container out-of-the-box (and wily should be able to run as unprivileged container)</div><div><br></div><div>If you only care about "having privileged containers running", then a centos host should work fine.</div><div><br></div><div>Back to your original question, you need to have some basic understanding of your distro's networking setup. For example, debian/ubuntu uses /etc/network/interfaces (one file for all network interfaces) while centos uses /etc/sysconfig/network-scripts/ifcfg-* (one file for each network interface). To achieve what you want, basically you need to create a bridge (e.g. br0) on top of your main network interface (e.g. eth0) that would be used by containers. The instructions are specific to your distro (e.g. centos and ubuntu are different), but not specific to lxc (i.e. the same bridge setup can be used by kvm/xen).</div><div><br></div><div>One bridge setup example (from google): <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces_network-bridge.html">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces_network-bridge.html</a></div><div><br></div><div>From the snippets you posted, you created "/etc/sysconfig/network-scripts/ifcfg-eth0", but you didn't mention where. If it's on the host, then you get it wrong, since you seem to be using "bond0" on the host. If it's in the container (which is correct), then the easiest way to check where the problems lie is with tcpdump: </div><div>- on the container: "ping -n 172.16.0.1"</div><div>- on the host: "tcpdump -n -i bond0 172.16.0.1" and "tcpdump -n -i veth5BJDXU 172.16.0.1" (substitute the veth name with whatever you have)</div><div><br></div><div>If all goes well, you should see both icmp reply and request on both interfaces (bond0 and veth5BJDXU). If you have forwarding problems, you will see packets on veth interface, but not on bond0.</div><div><br></div><div>-- </div><div>Fajar</div><div><br></div><div><br></div><div><br></div></div></div></div>