<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 6:09 PM, Fajar A. Nugraha <span dir="ltr"><<a href="mailto:list@fajar.net" target="_blank">list@fajar.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>eth2 already works. I set it up for testing outside of all containers (i.e. on the host only). From the host:</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>That doesn't match what you said earlier.</div></div></div></div></blockquote><div><br></div><div>It actually does. Remember that this LXC host is a virtual machine running off of VMware, which makes this whole situation more complex. I'll try to clarify.</div><div><br></div><div>VLAN10, the native vlan, is <a href="http://192.168.54.0/25">192.168.54.0/25</a>. It's my management vlan</div><div>VLAN500 is <a href="http://10.240.78.0/24">10.240.78.0/24</a>.</div><div><br></div><div>eth1 and eth2 are setup to connect to vlan500 because they were setup that way through VMware. Normarlly you would be correct, on a physical server eth2 would only be able to contact the native vlan, because no tagging information is provided. However VMware allows you to tag a NIC (its actually called a port group, but it is essentially VMware's way of saying a NIC) from outside the VM guest. If you do this (as I have) then you don't (and shouldn't) need to tag anything on the VM guest itself. So by just looking at the guest it can look incorrect/confusing.</div><div><br></div><div>My original problem was I was tagging the port group (a.k.a. VMware's NIC) and I was tagging eth1 inside the VM guest (a.k.a. the LXC host). Clearly this causes problems. Because I was tagging eth1 but not eth2 that is where the problem resided. I was trying to mimic a setup I have in my home lab where I tag an Ethernet device, add it to a bridge, then use that bridge in a container, but my home lab uses a physical LXC host. Hopefully I've explained it in a way that clears this up.</div><div><br></div><div>Either way I have that problem resolved. Now I'm just wondering why the container is not adding the gateway's MAC address when it ARP's for it (as I explained in my last email).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>What I meant, check that ETH1 works on the host. If eth2 is on the same network, it might interfere with settings. So disable eth2 first, then test eth1 on the host. Without bridging.</div></div></div></div></blockquote><div><br></div><div>Okay that makes sense. </div><div><br></div><div>Thanks,</div><div>Joshua</div></div></div></div>