back
2 comments
As mentioned in https://github.com/docker/docker/issues/3043#issuecomment-51..., multicast works in bridge driver. It works for the default docker0 bridge network and also other user-defined bridge networks.

Docker 1.9 brought in Native multi-host networking support using overlay driver. Proper multicast support for the overlay driver would require proper multicast control-plane (L2 & L3). Contributions welcome.

http://github.com/weaveworks/weave enables multicast between containers (and many other things besides).
Yeah, but I needed this for scenarios where I managed the Docker bridge directly - i.e., running a set of streaming servers that are an insane hassle to set up and required frequent upgrades. Docker was perfect for building, upgrading and deploying them.

Weave would just get in the way in this scenario (and has a tendency to over-complicate simple stuff like running an ElasticSearch cluster with auto discovery)

Weaveworker here:

I'd love to know what you mean by "over-complicate". It can be as simple as `docker run --net=weave ...`.

We have a PR open that would let you connect Docker's bridge to Weave Net - https://github.com/weaveworks/weave/pull/1955

Thanks for letting me know, but it's still open, right?

Besides, can't we all just get along and accept that I might want to do things in a specific way because I don't need the extra overhead? :)

> Weave ... has a tendency to over-complicate simple stuff like running an ElasticSearch cluster with auto discovery

Elasticsearch autodiscovery relies on multicast, AFAIK the only way to get it working with Docker is to use Weave (or another overlay network that gives you multicast). Is that not correct?

That is precisely my point. I want to do it without weave. As long as I can control the Docker bridge (and be responsible about it), I should be able to just do it.