Podman: `podman create --mac-address` doesn't work

[runiq]

/kind bug

Description

The --mac-address switch to podman create/podman run doesn't work.

Steps to reproduce the issue:

# podman run --rm -it --mac-address=02:23:45:67:89:ab registry.fedoraproject.org/fedora-minimal:28 cat /sys/class/net/eth0/address
0a:58:0a:58:01:5a

Describe the results you received:

An automatically-assigned MAC address.

Describe the results you expected:

The MAC address I specifiied in the argument.

Output of podman version:

Version:       0.7.2
Go Version:    go1.10.3
OS/Arch:       linux/amd64

Output of podman info:

Output of podman info

host:
  MemFree: 8406614016
  MemTotal: 16652193792
  SwapFree: 8398041088
  SwapTotal: 8398041088
  arch: amd64
  cpus: 4
  hostname: trabajo.itz.uni-halle.de
  kernel: 4.17.6-200.fc28.x86_64
  os: linux
  uptime: 20m 9.95s
insecure registries:
  registries:
  - trabajo.itz.uni-halle.de:5000
registries:
  registries:
  - trabajo.itz.uni-halle.de:5000
  - registry.fedoraproject.org
  - docker.io
store:
  ContainerStore:
    number: 0
  GraphDriverName: vfs
  GraphOptions: []
  GraphRoot: /home/ajaam/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 1
  RunRoot: /run/user/29574/run

Additional environment details (AWS, VirtualBox, physical, etc.):

Contents of /etc/cni/net.d/87-podman-bridge.conflist

{
    "cniVersion": "0.3.0",
    "name": "podman",
    "plugins": [
      {
        "type": "bridge",
        "bridge": "cni0",
        "isGateway": true,
        "ipMasq": true,
        "ipam": {
            "type": "host-local",
            "subnet": "10.88.0.0/16",
            "routes": [
                { "dst": "0.0.0.0/0" }
            ]
        }
      },
      {
        "type": "portmap",
        "capabilities": {
          "portMappings": true
        }
      }
    ]
}

[mheon]

@rhatdan Looks like we missed a flag when we were removing options CNI doesn't support...

@runiq Thanks. Don't know when we'll be able to implement this, given that our network backend (CNI plugins) doesn't really offer support for this. We may end up disabling the flag until this happens.

[runiq]

No worries, for the use-case I'm eyeing (node-locked license server in container) I can use docker in the meantime.

[mbaudier]

Is it planned to support setting mac addresses at some point? I have the same issue as @runiq, but since this is a new deployment I would have liked to avoid docker and use podman from the start.

I have also tried setting the mac adress via ip link set dev eth0 address in the container, but it doesn't work (RTNETLINK answers: Operation not permitted) which is probably not surprising.

[mheon]

@mccv1r0 Is there any ability for us to set the MAC address for bridge networks in CNI?

[mccv1r0]

Is there any ability for us to set the MAC address for bridge networks in CNI?

See tuning plugin. The mac well known capabilities is probably what you want vs setting mac in a .conflist file. This page also reads like CNI_ARGS works too, but check if CNI_ARGS is being deprecated.

[mbaudier]

Thanks for your quick answers. I am testing on CentOS 7 (podman v1.3.2, containernetworking-plugins v0.7.5, from the 'extras' repository):

• CNI_ARGS doesn't recognize the MAC argument:

CNI_ARGS="MAC=c2:11:22:33:44:55" podman run -it centos
ERRO[0000] Error adding network: ARGS: unknown args ["MAC=c2:11:22:33:44:55"]

(I tested the 'IP' argument to see whether CNI_ARGS works and the IP address was properly set)

• I added a 'tuning' plugin section in the provided /etc/cni/net.d/87-podman-bridge.conflist

...
      {
        "type": "tuning",
        "capabilities": {
          "mac": true
        }
      }

and also tried to explicitly set the MAC address at various locations in this file (in the plugin definition, as args, etc.) but to no avail.

I think that I am missing something with how the chaining of plugins is working. (I mostly tried to understand network-configuration-lists)

Should I define additional files?
How can I somehow map a given container/image/ip address/some criterion to a MAC address in the conflist file?

[mheon]

Reopening this given that it does seem possible on the CNI side.

[mccv1r0]

Been on PTO until today. I used this just now to test that the containers MAC address can be set using up to date CNI and plugins.

cnitool simulates a runtime such as podman. First set CAP_ARGS to tell cnitool what it should feed CNI as the runtime supplied capabilities:

$ export CAP_ARGS='{
    "portMappings": [
        { "hostPort": 9092, "containerPort": 92, "protocol": "sctp" },
        { "hostPort": 9092, "containerPort": 92, "protocol": "tcp" }
    ],
    "mac": "02:22:33:44:55:66" 
}'

Now run cnitool:

$ cnitool add portmap-mac-mcc2-range-chain /var/run/netns/mcc-cni-test0
{
    "cniVersion": "0.4.0",
    "interfaces": [
        {
            "name": "mcc2",
            "mac": "96:cf:3a:cf:31:62"
        },
        {
            "name": "vetha0536c8a",
            "mac": "96:cf:3a:cf:31:62"
        },
        {
            "name": "ens2",
            "mac": "02:22:33:44:55:66",
            "sandbox": "/var/run/netns/mcc-cni-test0"
        }
    ],
    "ips": [
        {
            "version": "4",
            "interface": 2,
            "address": "10.2.0.4/24",
            "gateway": "10.2.0.1"
        }
    ],
    "dns": {
        "nameservers": [
            "8.8.8.4"
        ]
    }
}

The corresponding conflist is:

{
        "name": "portmap-mac-mcc2-range-chain",
        "cniVersion": "0.4.0",
        "plugins": [{
                        "type": "bridge",
                        "bridge": "mcc2",
                        "ipMasq": true,
                        "isGateway": false,
                        "ipam": {
                                "type": "host-local",
                                "ranges": [
                                        [{
                                                "subnet": "10.2.0.0/24",
                                                "rangeStart": "10.2.0.2",
                                                "rangeEnd": "10.2.0.220",
                                                "gateway": "10.2.0.1"
                                        }]
                                ],

                        },
                        "dns": {
                                "nameservers": ["8.8.8.4"]
                        }
                },
                {
                        "type": "portmap",
                        "capabilities": {
                                "portMappings": true
                        }
                },
                {
                        "name": "mytuning",
                        "type": "tuning",
                        "capabilities": {
                                "mac": true
                        },
                        "sysctl": {
                                "net.core.somaxconn": "500"
                        }
                }
        ]
}

[mheon]

Alright. Based on this, we need small changes to the ocicni wrapper to allow setting "mac" in CNI args, plus a small change to the plugins section of our default CNI config.

[rhatdan]

@mheon Is this something we can get in for podman 1.5 along with IPV6 support? Seems like a nice feature to add.

[mheon]

Sure, I think this is a good candidate for 1.5.

On Thu, Aug 1, 2019, 05:30 Daniel J Walsh [e-mail] wrote:

@mheon https://github.com/mheon Is this something we can get in for
podman 1.5 along with IPV6 support? Seems like a nice feature to add.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/1136?email_source=notifications&email_token=AB3AOCHAICGFQDT2UYMAGCLQCKUJ5A5CNFSM4FLMURAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3J7BTQ#issuecomment-517206222,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB3AOCG3SIPOJQJJOLCXVQLQCKUJ5ANCNFSM4FLMURAA
.

[rhatdan]

@mheon Since this did not make the 1.5 release. Could you make this feature work in the next week or so, or should we assign it to someone else?

[mheon]

My target here is 1.5.1 or .2.

On Sat, Aug 10, 2019, 06:01 Daniel J Walsh [e-mail] wrote:

@mheon https://github.com/mheon Since this did not make the 1.5
release. Could you make this feature work in the next week or so, or should
we assign it to someone else?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/1136?email_source=notifications&email_token=AB3AOCFA3EY6UXZSAPRUB43QD2GZLA5CNFSM4FLMURAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AKMLY#issuecomment-520136239,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB3AOCEILOKTU3HW6AWUT63QD2GZLANCNFSM4FLMURAA
.

[baude]

make a card!

[filak-sap]

Any progress? I need run --mac-address too.

[mheon]

On my list of priorities, it's around position 3 - after volume plugin support (working on this now) and IPv6 support.

[filak-sap]

@mheon Any hints on how to implement this feature?

[mheon]

First step is to modify OCICNI to allow the MAC address to be passed in as part of CNI args - https://github.com/cri-o/ocicni/

Then we vendor the new OCICNI library, and add handling for --mac-address in Podman itself

[filak-sap]

Shall we use the tunning plugin as proposed at: https://github.com/intel/multus-cni/issues/266#issuecomment-465837978 ?

[filak-sap]

This seems to be naive:

diff --git a/pkg/ocicni/ocicni.go b/pkg/ocicni/ocicni.go
index 88d1806..adbd0a0 100644
--- a/pkg/ocicni/ocicni.go
+++ b/pkg/ocicni/ocicni.go
@@ -819,6 +819,15 @@ func buildCNIRuntimeConf(cacheDir string, podNetwork *PodNetwork, ifName string,
                rt.Args = append(rt.Args, [2]string{"IP", ip})
        }

+       // Add the requested static MAC to CNI_ARGS
+       mac := runtimeConfig.MAC
+       if mac != "" {
+               if tstMAC := net.ParseMAC(mac); tstMAC == nil {
+                       return nil, fmt.Errorf("unable to parse MAC address %q", mac)
+               }
+               rt.Args = append(rt.Args, [2]string{"MAC", mac})
+       }
+
        // Set PortMappings in Capabilities
        if len(runtimeConfig.PortMappings) != 0 {
                rt.CapabilityArgs["portMappings"] = runtimeConfig.PortMappings
diff --git a/pkg/ocicni/types.go b/pkg/ocicni/types.go
index af013ae..717ecda 100644
--- a/pkg/ocicni/types.go
+++ b/pkg/ocicni/types.go
@@ -44,6 +44,9 @@ type RuntimeConfig struct {
        // with the hostlocal IP allocator. If left unset, an IP will be
        // dynamically allocated.
        IP string
+       // MAC is a static MAC address to be assigned to the network interface.
+       // If left unset, a MAC will be dynamically allocated.
+       MAC string
        // PortMappings is the port mapping of the sandbox.
        PortMappings []PortMapping
        // Bandwidth is the bandwidth limiting of the pod

[mheon]

That looks like it could well be enough - if you're able to PR this against OCICNI, I think there's a good chance they'll accept it.

[filak-sap]

I could not resist to play with a little bit (not compiled nor tested):
https://github.com/filak-sap/libpod/commit/9abe0ad1228140e0690595a5f762f00ed49b2bb9

[rhatdan]

@filak-sap That looks pretty good, open a WIP PR and we can look at fixing ocicni.

[mheon]

I got a few knits, but overall those changes LGTM

[filak-sap]

I managed to build it - #4058

[github-actions[bot]]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[rhatdan]

Since we have a PR for this, we are not that far away from gaining support. We need someone to take over for @filak-sap to push it over the finish line.

[runiq]

Awesome, thanks everyone, much appreciated!

[rhatdan]

No problem, keep the issues coming. They help make Podman into a better project.

[leier69]

I can still not assign static IP to container using following command:
podman create --net podnet -v /etc/nginx:/etc/nginx:ro --mac-address=3e:84:ea:ab:7d:51 -p 80:80 -p 443:443 --restart=on-failure:3 docker.io/library/nginx

fedora 30
podman 1.7

please assist me, I need this to work

[mheon]

Providing an error message might be helpful - hard to tell what's going wrong from just the command?

[leier69]

There is no error, I just does not get the mac address im assigning an mac

from inspect:
```"CreateCommand": [
"podman",
"create",
"--net",
"podnet",
"-v",
"/etc/nginx:/etc/nginx:ro",
"--mac-address=3e:84:ea:ab:7d:51",
...
"MacAddress": "3e:84:ea:ab:7d:51"

CNI conf:
```{
   "cniVersion": "0.4.0",
   "name": "podnet",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br0",
         "ipam": {
            "type": "dhcp"
         }
      },
      {
        "type": "tuning",
        "capabilities": {
          "mac": true
      }
      }
   ]
}

[leier69]

Fuck. They match up...

[mheon]

I did a quick check and verified with ifconfig inside a container - looks like the flag is working as expected

[leier69]

But its acually still a issue for me, because I didnt acually fuck up. It was this mac that sendt a request to my dhcp server: 0a:dd:5b:ce:23:d1

Why? how am I suppose to set static IPs in pfsense then? whats happening?

[baude]

do you actually want to be doing a macvlan connection?

[leier69]

No I need the containers to connect to my bridge, which is the lan adapter in pf sense. Therefore i would like them to make dhcp requests with the same mac everytime. Please help

[mheon]

Hm. So you're using a pre-established bridge, configured elsewhere? And CNI is making DHCP requests using a different MAC?

[leier69]

Yup, I would like my containers to jump on that bridge, since I have VMs and other things there, is this a problem with cni plugins? Or is it misconfiguration on my part?

[rhatdan]

@mccv1r0 Thoughts?

[mccv1r0]

When I try to reproduce, I get an error Error: cannot parse 3e:84:eaab7d:51 as MAC address: address 3e:84:eaab7d:51: invalid MAC address: invalid argument

Is --mac-address=3e:84:eaab7d:51 the actual syntax?

I am using:

podman version 1.7.0 on Fedora 30

[mheon]

Is there a missing :? --mac-address=3e:84:ea:ab:7d:51

[mccv1r0]

$ sudo podman create --net podman  --mac-address="3e:84:eaab7d:51" -p 80:80 -p 443:443 --restart=on-failure:3 docker.io/library/nginx 
Error: cannot parse 3e:84:eaab7d:51 as MAC address: address 3e:84:eaab7d:51: invalid MAC address: invalid argument

I tried with and without double quotes

[mccv1r0]

*&%# never mind... cut/paste error

[leier69]

Okai so my issue is the following. Im using this network-conf:

{
   "cniVersion": "0.4.0",
   "name": "podnet",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br0",
         "ipam": {
            "type": "dhcp"
         }
      },
      {
        "type": "tuning",
        "capabilities": {
          "mac": true
      }
      }
   ]
}

I want my containers to jump on the bridge and to get a ip from the dhcp, this combined with the --mac-address would make it super easy to assign static IP adresses in pfsense which is running a dchp server. My problem is that the dhcp cli plugin
/usr/libexec/cni/dhcp daemon & is not presenting the dhcp server with the macaddress specified, but rather with one randomly generated.

All help is very appriciated

[leier69]

@mccv1r0 @mheon @rhatdan
Thoughts?

[mccv1r0]

Things seem to work when using host-local (for a quick test):

$ sudo podman run -d --net podman --name="testMac"  --mac-address=3e:84:ea:ab:7d:52 socksink-sudo  
115c0a0831d5cb0a5b4d547ef29c7577e19c8a0f7b7b23c28730bacca5a1e337
$ sudo podman exec testMac ip link show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth0@if47: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 3e:84:ea:ab:7d:52 brd ff:ff:ff:ff:ff:ff
$ 
$ sudo podman run -d --net podman --name="testMac-aa"  --mac-address=3e:84:ea:ab:7d:aa socksink-sudo  
7f34432208191f2c4984af5ca9306d492200c0fc8c4da3d562861bf75c32c8ae
$ sudo podman exec testMac-aa ip link show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth0@if48: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 3e:84:ea:ab:7d:aa brd ff:ff:ff:ff:ff:ff
$ 

I don't have dhcp plugin setup yet. While I do that, @leier69, in your failing case, can you run ip link show (vs inspect) to see what iproute2 thinks the mac address is?

[mccv1r0]

I still don't have dhcp setup fully, but I might not need to. Using tcpdump on the bridge, I don't see the right mac address in the dhcp request. In one window:

$ sudo podman run -d --net podnet --name="testMac-aa"  --mac-address=3e:84:ea:ab:7d:aa socksink-sudo

In the tcpdump window, I'd expect to see 3e:84:ea:ab:7d:aa but don't.

[mcambria@mcambria dwhelper]$ sudo tcpdump -n -i podnet0 ip and udp 
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on podnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:34:09.570215 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 16:ea:58:20:a6:1a, length 326
13:34:18.203928 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 16:ea:58:20:a6:1a, length 326
13:34:31.196745 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 16:ea:58:20:a6:1a, length 326

@leier69 Can you verify this on your setup? That is, run tcpdump on your bridge etc. confirm the mac seen by dhcp server matches tcpdump/container etc?

If you do, open an issue in CNI Plugins. It looks like the issue is specific to the CNI dhcp client plugin.

[leier69]

created issue https://github.com/containernetworking/plugins/issues/450.

Please comment on it to further its progress @mccv1r0

and 1000 times thanks @mccv1r0 ! <3 this gives me hope to have this setup work smoothly