Promiscious mode needed on network device

[lab-w]

To access the IPs from outside the docker containers it is necessary to set the network adapter into promiscuous mode. In Ubuntu this is possible with: ip link set eth1 promisc on Maybe you could add a hint to the readme file?

[rhastie]

You are correct. Docker does this via the MACVLAN network driver.

I am a little concerned that you've had to do this manually. The advantage of using Compose with the MACVLAN driver is that Docker should automatically configure promiscuous mode for you when the containers start and de-configure it when the containers are stopped.

Easy-NMOS has been extensively tested under Ubuntu on both 18.04 and 20.04 LTS releases and manually enabling promiscuous mode was not required.

Did you correctly configure your "parent" adapter in the Docker-compose.yml file? Could you share your server configuration (particularly your NIC vendor/driver), your Docker version and Compose version?

Thanks...

[lab-w]

Thank you for your detailed explanation. Seems you are right and some other setting might be the reason promiscuous mode was not working for me (but now it works): I'm using a Ubuntu 18.04 VM (VMware) on a Windows host. After it was not working I enabled promiscuous mode in the vmx file of my VM (like described here: https://superuser.com/questions/1209497/how-do-you-enable-promiscuous-mode-in-vmware-workstation). Unsure if it's necessary and if its the only way to do this. I'm using VMware Workstation Player 15.

[rhastie]

Ahh... This makes much more sense now... I'm glad you got the containers functioning

When running this stack inside VMs you do tend to have to authorise the use of promiscuous mode at the hypervisor layer. This is typically because you want to get the containers exposed to the external physical machine network via the Paravirtualized NIC in the VM. ie. so devices on your physical LAN can interact with the registry etc. With a hypervisor you are effectively adding a third-layer of abstraction to the implementation and that also needs configuring correctly. One alternative to this approach is to use SR-IOV - SR-IOV is another topic in itself.

I have had similar experiences when running using VirtualBox under Windows and VMWare Fusion under Mac. Hypervisors tend to consider promiscuous mode as a potential security risk hence why explicit authority is needed. In my case, once promiscuous mode was enabled both hypervisors successfully worked.

Even though the containers have been tested under several hypervisors it's impossible to cover all the scenarios - all the hypervisors do slightly different things and in slightly different ways. At this stage detailing support for hypervisor usage is beyond the resources of the project. At some point we may add documentation for specific known hypervisor scenarios to the README.md.

In the interim, I'm quite happy to try and offer assistance on a case by case basis. Glad you got it working! Thanks.

[rbgodwin]

Hi Rich! I thought at first I had a similar problem as this issue. After struggling around some I found my problem (which might be common for newbies like myself with docker) was that I was trying to run my browser on the same machine as my docker containers. For my system it simply didn't work. I saw it referenced on a macvlan posting that it's by design. Worked fine when I accessed from another machine though. Docker bridge network doesn't seem to have this behavior and I could run my browser on the same machine.

I might have missed it and it might be dependent on versions somehow but for my 18.04 Ubuntu that's how it works for me. Maybe a little note on the Readme page if you confirm this is the behavior.

PS: Thanks for a great git repo! I'm up and running now and registering my own local nodes.