<div dir="ltr"><div class="gmail_default" style="font-size:small">That scheme in my case would not work. I have two interfaces inside the container, and each one talks to a different network, for business reasons. I use policy-based-routing to make sure that packets go to the right places. I need that the container can hold a full configuration. In my case, I use ifupdown, not netplan, since my containers are for an older version of Debian.</div><div class="gmail_default" style="font-size:small">It is "not right" that ipvlan does not work out-of-the-box like macvlan or veth. Somebody has to fix it. I cannot use macvlan because Vmware only allows multiple macs if the entire network is set in promiscuous mode, and that kills performance. So basically the only workaround is ipvlan. As I said, if you use type=phys and ipvlan inside the host, it works fine, without altering the container.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 4:20 AM Fajar A. Nugraha <<a href="mailto:list@fajar.net">list@fajar.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 23, 2020 at 11:48 PM Saint Michael <<a href="mailto:venefax@gmail.com" target="_blank">venefax@gmail.com</a>> wrote:<br>
><br>
> It is supported, there is no error, but there is no communication at all with the gateway. If you start the same exact network configuration in the container with the type=phys, it works fine, ergo, the issue is type=ipvlan.<br>
<br>
"exact network configuration" inside the container? I'm pretty sure it<br>
would fail.<br>
<br>
If you read what I wrote earlier:<br>
"<br>
set /etc/resolv.conf on the container manually, and disable network<br>
interface setup inside the container.<br>
"<br>
<br>
This works in my test (using lxc 3.2.1 from<br>
<a href="https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/daily" rel="noreferrer" target="_blank">https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/daily</a>):<br>
# Network configuration<br>
<a href="http://lxc.net.0.name" rel="noreferrer" target="_blank">lxc.net.0.name</a> = eth0<br>
lxc.net.0.type = ipvlan<br>
lxc.net.0.ipvlan.mode = l3s<br>
lxc.net.0.l2proxy = 1<br>
lxc.net.0.link = eth0<br>
lxc.net.0.ipv4.gateway = dev<br>
lxc.net.0.ipv4.address = <a href="http://10.0.3.222/32" rel="noreferrer" target="_blank">10.0.3.222/32</a><br>
lxc.net.0.flags = up<br>
<br>
<br>
While inside the container, setup resolv.conf manually, and disable<br>
networking setup (e.g. removing everything under /etc/netplan/ on<br>
ubuntu should work).<br>
<br>
Common issue with macvlan/ipvlan of "container not being able to<br>
contact the host" would still apply.<br>
<br>
-- <br>
Fajar<br>
_______________________________________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org" target="_blank">lxc-users@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" rel="noreferrer" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a><br>
</blockquote></div>