libnetwork
libnetwork copied to clipboard
moby
macvlan / ipvlan parent interface (e.g. en0 instead of eth0) broken on Mac OSX
It appears the docker macvlan / ipvlan drivers expect parent (host) interfaces to follow linux-like interface naming (e.g. eth0 as a prefix) and break when faced w/ Mac OSX interface naming (e.g. en0)
When trying to set up a macvlan on Mac OSX w/ the primary network interface en0 as so:
docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=en0 pub_net
The attempt fails with:
Error response from daemon: invalid subinterface vlan name en0, example formatting is eth0.10 see https://github.com/moby/libnetwork/blob/d0951081b35fa4216fc4f0064bf065beeb55a74b/drivers/macvlan/macvlan_setup.go#L110
When trying to set up a 802.1q trunk macvlan as so:
docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=en0.86 pub_net_86
The attempt fails with:
Error response from daemon: -o parent interface does was not found on the host: en0 see https://github.com/moby/libnetwork/blob/d0951081b35fa4216fc4f0064bf065beeb55a74b/drivers/macvlan/macvlan_setup.go#L155
The same commands execute without complaint when eth0 instead of en0 is used, but since eth0 doesn't actually exist on the host, the containers are isolated from the network.
This issue was raised in https://github.com/docker/for-mac/issues/3926 but probably didn't get any visibility there. Hopefully it'll get noticed here.
yeah, I recently looked into using macvlans and stumbled upon this..quite surprised this hasnt been fixed yet..
Unfortunately, the documentation specifies it not supported (yet?) on Windows and MacOS : https://docs.docker.com/network/network-tutorial-macvlan/ It would be useful to do it, I hope they implement it someday.
Yeah having similar issues with an ubuntu installation - neither network adapter gets a standard name
Yeah having similar issues with an ubuntu installation - neither network adapter gets a standard name
same issue here:
just installed docker desktop, on ubuntu 23.04. So this is all newer versions of docker...
The process of installing docker desktop seemed to kill / destroy existing containers, and existing docker network definintions. So when trying to re-create the docker network. With same commands as had always worked before...
Error response from daemon: invalid subinterface vlan name enp4s0f1, example formatting is eth0.10
It has broken / regressed.
I believe that this bug might be related with the following changeset:
https://github.com/moby/libnetwork/commit/3a4b08f0b1869594adb1fdcf94b5cb3b8d544bdc
for sure, the bug occurs here:
~~https://github.com/moby/libnetwork/blob/master/drivers/macvlan/macvlan_network.go#L91~~ https://github.com/moby/moby/blob/master/libnetwork/drivers/macvlan/macvlan_network.go#L70
Maybe if the !parentExists() function (the logic of it) is only recognizing the eth0 naming convention? That would be the bug then? That this bit is not evaluating correctly?
~~https://github.com/moby/libnetwork/blob/master/drivers/macvlan/macvlan_setup.go#L67~~ https://github.com/moby/moby/blob/master/libnetwork/drivers/macvlan/macvlan_setup.go#L70
the ns.NlHandle().LinkByName(ifaceStr)
???
[REASON FOR EDIT] the repo code was moved to other repo now: (but is same exact code)
maybe can you help us understand this bug @arkodg ?
Sorry I am not familiar with go code, and these library functions that is being called out to. However this seems like where the error is happens. For any systems with an interface name... which isn't eth0 style
That the call ns.NlHandle().LinkByName(ifaceStr) may be failing.
BTW this code is duplicated between both the ipvlan and macvlan driver backends, if andthing needs fixing there too. Otherwise perhaps it is the underlying common library function is calling out to and failing to return the correct answer? (that, for example: en0 exists on the host as some real valid interface name).
OK. So here are some candidate bugs for the upstream library (the netlink is maintained by somebody else...)
https://github.com/vishvananda/netlink/issues/791
https://github.com/vishvananda/netlink/issues/755
https://github.com/vishvananda/netlink/issues/438
https://github.com/vishvananda/netlink/issues/325
However just don't have here the visibility (knowledge) to check which specific version of the netlink library my local docker installation was compiled to be using here. And I don't really have this same level of familiarity to go in here and try recompiling this macvlan driver from the git / to try with speculative edits and so on to those critical code path. To test out these theory. And give clearer answers
But until then... my docker is totally broken :(
Of course I can still provide some extra infos (such as specific docker version, exact kernel version). And follow some extra instructions / replace some binaries or .so file. It does not seem too challenging (at least not so far). Any further help is very much appreciated. And it seems "enough"? other people are affected? If indeed this matter was not fixed already?
Seems like this issue was 1st reported all the ways back in 2019 perhaps? (but was never looked at)
https://github.com/docker/for-mac/issues/3447
However this bug seems significant! I would recommend at least some look at it, if not should be considered looking towards critical / important / higher priority. Along those lines
Seems like this issue was 1st reported all the ways back in 2019 perhaps? (but was never looked at)
However this bug seems significant! I would recommend at least some look at it, if not should be considered looking towards critical / important / higher priority. Along those lines
Documentation says this is not supported in Mac which sux. no idea why they cant fix it sicne 4 years. Just run into this issue and now looking into how i do i get a workaround with it.
Seems like this issue was 1st reported all the ways back in 2019 perhaps? (but was never looked at) docker/for-mac#3447 However this bug seems significant! I would recommend at least some look at it, if not should be considered looking towards critical / important / higher priority. Along those lines
Documentation says this is not supported in Mac which sux. no idea why they cant fix it sicne 4 years. Just run into this issue and now looking into how i do i get a workaround with it.
Did you get any workaround ?
