Right now the OS generates random MAC addresses for the container interfaces bound to it. To prevent clashes, we should provide an optional explict MAC address assignment, e.g. with a "--mac ..." option to 'weave run'.
It is useful when a software license is bound to a specific mac address. Actually esential in some cases.
See also https://github.com/weaveworks/weave/issues/2870.
This is definitely a big issue for me. The only way to get the app running is via a) MAC addressed-based license, b) a dongle on the host, c) a license server with also a dongle.
b) is no option in the cloud.
c) is no option either since I cannot use a license server that will be hidden behind a fire wall.
For weave launch, do we want both --mac and --name, or should we make --name set the weave bridge mac?
I would say --mac for setting the mac address and --name for setting the container name.
My question is about the "peer name" that weave gives iswmf,not a container name.
Perhaps we shouldn't bother with explicit mac assignments for the weave bridge. It's not required for the "I want to run some software in a container that has a license which is tied to a specific MAC address" use case. And it's not really needed for the "prevent clashes" use case either since the number of hosts is typically far smaller than the number of containers and doesn't churn as much.
Note that the current behaviour is not to set it randomly; #1866 changed this to set it from the machine ID where available, which gives us problems where the machine ID is the same across hosts.
Either adding --mac or using --name would give users a way out of that problem, pending their machine provider making the IDs unique.
Ah yes; I thought we had a separate issue for that - #2606 is related but doesn't mention the MAC clash problem.
In any case, settings macs for containers and setting the mac of the weave bridge are completely different issues, and, I suspect, completely different pieces of code. So I'd rather tackle only the former in here.
Created #2900 and edited the description of this issue to limit it to container MACs.
Just a check from me if adding the ability to set the container MAC address is still considered. The inability to set the address still prevents me from using WeaveNet for those containers.
Whether allowing MAC address setting of ethernet card will result in software piracy/ unauthorised use of licensed software bound to specific MAC address?
Whether allowing MAC address setting of ethernet card will result in software piracy/ unauthorised use of licensed software bound to specific MAC address?
Licensed software using a mac address based enforcement mecanism is one use case yes. It is an important use case. However I think software piracy is rarely the reason. More often it is because the software wasn't designed for the cloud.
I have a somewhat related issue/use-case.
I am running a K8s cluster on a set of Raspberry PIs that are basically cloned images, and for some reason the weave interface has the same MAC on all machines (running it through K8s). That leads to a lot of trouble, but I can set the MAC explicitly with ifconfig weave hw ether $MAC to a more random value and it fixes it.
Is that a use-case for this feature? How is the MAC generated anyway? Is that a typical issue in containerized environments?
@marcust please see https://www.weave.works/docs/net/latest/faq/#duplicate-peer
Most helpful comment
Just a check from me if adding the ability to set the container MAC address is still considered. The inability to set the address still prevents me from using WeaveNet for those containers.