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

Using mac_address with multiple networks is unreliable in Compose V2 #9076

Closed
bpascard opened this issue Jan 3, 2022 · 0 comments · Fixed by #9130
Closed

Using mac_address with multiple networks is unreliable in Compose V2 #9076

bpascard opened this issue Jan 3, 2022 · 0 comments · Fixed by #9130

Comments

@bpascard
Copy link

bpascard commented Jan 3, 2022

Description

In Compose V1 if a service is attached to multiple networks and mac_address is set the chosen MAC is applied to the interface of the network with the highest priority. Network priority is determined based on the priority property (if set), and otherwise falls back to being based on the alphabetical order of network names (highest first).
In Compose V2 the chosen MAC address seems to be randomly assigned to either network.

Steps to reproduce the issue:

  1. Use this compose file
services:
  web:
    image: alpine
    command: ip l
    networks:
      back:
        priority: 100
      front:
        priority: 1000
    mac_address: 00:bb:bb:bb:bb:bb
networks:
  front:
    driver_opts:
      com.docker.network.container_iface_prefix: front
  back:
    driver_opts:
      com.docker.network.container_iface_prefix: back
  1. Run docker-compose-v1 up
Attaching to bug-compose-mac_web_1
[...]
web_1  | 216: front0@if217: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
web_1  |     link/ether 00:bb:bb:bb:bb:bb brd ff:ff:ff:ff:ff:ff
web_1  | 218: back0@if219: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
web_1  |     link/ether 02:42:ac:15:00:02 brd ff:ff:ff:ff:ff:ff
bug-compose-mac_web_1 exited with code 0
  1. Run docker compose up
[+] Running 1/1
 ⠿ Container bug-compose-mac_web_1  Recreated                                                                                                                                                                 0.1s
Attaching to bug-compose-mac-web-1
[...]
bug-compose-mac-web-1  | 220: front0@if221: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
bug-compose-mac-web-1  |     link/ether 02:42:ac:14:00:02 brd ff:ff:ff:ff:ff:ff
bug-compose-mac-web-1  | 222: back0@if223: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
bug-compose-mac-web-1  |     link/ether 00:bb:bb:bb:bb:bb brd ff:ff:ff:ff:ff:ff
bug-compose-mac-web-1 exited with code 0

Describe the results you received:

With compose v1, 00:bb:bb:bb:bb:bb is affected to front0.
With compose v2, 00:bb:bb:bb:bb:bb is affected to back0.

Describe the results you expected:

I expected 00:bb:bb:bb:bb:bb to always be affected to front0 in v2 because front has higher priority, just like in v1.

Additional information you deem important (e.g. issue happens only occasionally):

In V2 it seems like the network to which mac_address is assigned to is random and unpredictable, or if there's any logic I couldn't understand it. I've had occasions where even a totally minute modification like changing priorities to 100/100 instead of 10/100 or changing the service command and that alone flipped the attribution of the MAC between front0 and back0.

Output of docker compose version:

Docker Compose version v2.2.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.1)
  scan: Docker Scan (Docker Inc., v0.14.0)

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 10
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.94GiB
 Name: docker-desktop
 ID: W762:H2DL:BGE6:C4RJ:JM5Z:DBN5:IOQS:CHPW:AJQA:WOVU:E2QN:GPAM
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 44
  Goroutines: 46
  System Time: 2022-01-03T22:32:18.122512425Z
  EventsListeners: 3
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
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

Successfully merging a pull request may close this issue.

1 participant