Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macvlan / ipvlan parent interface (e.g. en0 instead of eth0) broken on Mac OSX #2614

Closed
claudobahn opened this issue Jan 22, 2021 · 31 comments
Closed

Comments

@claudobahn
Copy link

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

return fmt.Errorf("invalid subinterface vlan name %s, example formatting is eth0.10", parentName)

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

return "", 0, fmt.Errorf("-o parent interface does was not found on the host: %s", parent)

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 docker/for-mac#3926 but probably didn't get any visibility there. Hopefully it'll get noticed here.

@pkishino
Copy link

yeah, I recently looked into using macvlans and stumbled upon this..quite surprised this hasnt been fixed yet..

@arrrgi
Copy link

arrrgi commented Sep 26, 2021

+1

8 similar comments
@jkneer
Copy link

jkneer commented Nov 27, 2021

+1

@domgiles
Copy link

+1

@yd-null
Copy link

yd-null commented Dec 29, 2021

+1

@mgrofsky
Copy link

mgrofsky commented Feb 7, 2022

+1

@serkanmulayim
Copy link

+1

@r4881t
Copy link

r4881t commented Apr 8, 2022

+1

@tymoor
Copy link

tymoor commented Apr 17, 2022

+1

@defmost
Copy link

defmost commented Jun 9, 2022

+1

@kingozorg
Copy link

+1 Anyone has a solution?

@Shogobg
Copy link

Shogobg commented Jul 21, 2022

+1

1 similar comment
@atulagrawal6
Copy link

+1

@DannySauval
Copy link

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.

@mandroid19
Copy link

+1

@summeryqc
Copy link

I was supprised that this issue hasn't been solved for such a long time.

@Trasen
Copy link

Trasen commented Apr 13, 2023

Yeah having similar issues with an ubuntu installation - neither network adapter gets a standard name

@teyou
Copy link

teyou commented Apr 15, 2023

since macvlan not supported on MAC OSX, I ended up to use macvlan via multipass on OSX

@dreamcat4
Copy link

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.

@dreamcat4
Copy link

dreamcat4 commented Jun 7, 2023

I believe that this bug might be related with the following changeset:

3a4b08f

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)

@dreamcat4
Copy link

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).

@dreamcat4
Copy link

OK. So here are some candidate bugs for the upstream library (the netlink is maintained by somebody else...)

vishvananda/netlink#791

vishvananda/netlink#755

vishvananda/netlink#438

vishvananda/netlink#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?

@dreamcat4
Copy link

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

@miamilabs
Copy link

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.

@czcll49
Copy link

czcll49 commented Aug 3, 2023

Any fixes?

@norayr93
Copy link

Having the same issue on my Macos Ventura 13.x.x

@shukla2009
Copy link

same issue ...

@enzofrnt
Copy link

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 ?

@kajarit
Copy link

kajarit commented Oct 28, 2023

+1

1 similar comment
@nikjuice
Copy link

+1

@neersighted
Copy link
Member

While this repo is in a semi-archived state (only used by the Moby 20.10 branch), I am going to close this issue before the official archiving as it seems to be misleading people. libnetwork does not work natively on macOS; and the "issue" here is that because the networking code runs inside the Linux virtual machine of Docker Desktop, "native" networking modes like --net=host, ipvlan, and macvlan do not interoperate with the Darwin kernel like you expect.

I'd suggested interested users consult docker/roadmap#238 and the many issues linked to it (e.g. for macvlan).

@neersighted neersighted closed this as not planned Won't fix, can't repro, duplicate, stale Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests