DHCP ignores containers mac-address when sending DHCPREQUEST to server

Hi!

I'm opening this because I'm trying to make a Podman container to join a PFsense LAN network on a bridge using a static DHCP lease. I thought that when podman released 1.7 (supporting setting static mac-addresses) this would be an easy task. I was wrong.

So currently im using the following network config list:

[root@leierpc leier]# cat /etc/cni/net.d/podnet.conflist
{
   "cniVersion": "0.4.0",
   "name": "podnet",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br0",
         "ipam": {
            "type": "dhcp"
         }
      },
      {
        "type": "tuning",
        "capabilities": {
          "mac": true
      }
      }
   ]
}

And this works from a Podman perspective. It asks for a IP through the dhcp.sock and the mac-address sat is indeed static. From Podmans side of things.

[root@leierpc leier]# podman run -d --net podnet --name="testMac"  --mac-address=3e:84:ea:ab:7d:52 docker.io/library/debian tail -f /dev/null
2020/02/04 19:58:25 5a0841b3f0347378d14ce3f7673da0380a720cf1873bc9a768f98aacc42c9d39/podnet/eth0: acquiring lease
2020/02/04 19:58:26 5a0841b3f0347378d14ce3f7673da0380a720cf1873bc9a768f98aacc42c9d39/podnet/eth0: lease acquired, expiration is 2020-02-04 21:58:26.330024245 +0100 CET m=+13799.752185010
5a0841b3f0347378d14ce3f7673da0380a720cf1873bc9a768f98aacc42c9d39

[root@leierpc leier]# 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@if38: <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 link-netnsid 0

But the DHCP plugin (/usr/libexec/cni/dhcp daemon &) does not respect the containers mac-address and presents the DHCP server with a seemingly random mac-address.

[root@leierpc leier]# podman start testMac 
2020/02/04 20:15:24 5a0841b3f0347378d14ce3f7673da0380a720cf1873bc9a768f98aacc42c9d39/podnet/eth0: acquiring lease
2020/02/04 20:15:25 5a0841b3f0347378d14ce3f7673da0380a720cf1873bc9a768f98aacc42c9d39/podnet/eth0: lease acquired, expiration is 2020-02-04 22:15:25.249862644 +0100 CET m=+14818.672023419
testMac

The mac-address on container testMac is currently 3e:84:ea:ab:7d:52 and nowhere to be seen

[root@leierpc leier]# tcpdump -n -i br0
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:15:24.216490 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 12:9f:61:68:d7:a7, length 326
20:15:24.392415 IP6 :: > ff02::1:ff68:d7a7: ICMP6, neighbor solicitation, who has fe80::109f:61ff:fe68:d7a7, length 32

All help would be appriciated, thanku

[mccv1r0]

It looks like the tuning plugin doesn't set the mac address supplied by the runtime until after the ipam plugin has finished. So in the case of the dhcp plugin, the mac address used for e.g. dhcp discover, request etc will be the random mac was assigned by Linux.

@mars1024 @squeed any thoughts?

[mars1024]

@mars1024 @squeed any thoughts?

Just as the comments by @mccv1r0 , the set-mac-address action happens in chained plugin tuning after the interface plugin bridge where the DHCP request is sent from. So the DHCP is not requesting with your assigned MAC address but a random one generated by kernel.

For now, I haven't thought of a good solution for this.

cc @dcbw @bboreham for more help!

Something worth noting is that when I change the config to acually specify the mac-address like so:

{
   "cniVersion": "0.4.0",
   "name": "podnet",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br0",
         "ipam": {
            "type": "dhcp"
         }
      },
      {
        "type": "tuning",
        "capabilities": {
          "mac": 3e:84:ea:ab:7d:52
      }
      }
   ]
}

It works in the same way as setting it throught the "--mac-address" argument. This means that the DHCP is still presenting the server with a random mac : (

[bboreham]

One idea: we could create an "ip assign" plugin which could appear later in the chain, change the bridge plugin so it just creates the veth at layer 2 if no ipam is supplied.

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

That would solve the Issue but I think it would be a better idea to integrate it as an optional option in "tuning".
I was imagining something like this:

{
   "cniVersion": "0.4.0",
   "name": "podnet",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br0",
         "interface-share-mac": true,
         "ipam": {
            "type": "dhcp",
         }
      },
      {
        "type": "tuning",
        "capabilities": {
          "mac": true
          <or some option here>
      }
      }
   ]
}

interface-share-mac is a really bad name but I think it would be nicer to integrate it. It would be nice if you could just ask the mac plugin to use the containers mac instead of the interface's. or maybe an option under "type": "bridge" where you specify that the interface and container should have the same mac.

I would love to hear your thoughts on this @mccv1r0 @bboreham

[bboreham]

I suspect we are not understanding each other. I think the problem you have identified is that the tuning plugin runs after the bridge and dhcp plugins have finished, hence they cannot use the mac that it sets.

Hmm yea I see. Then ur solution is better, but still kind of feels like an extra step. Should not the default behavior of CNI be to look over the conf before setting an interface mac at random?

so where do we take this now @bboreham ? Do you know anybody that could help?

[bboreham]

Under CNI chaining, each plugin runs independently and with zero knowledge of what any other plugin does. The whole idea of CNI is that plugins can come from anywhere.
There are some videos where we explain the design of CNI and how the project works, e.g. https://www.youtube.com/watch?v=YjjrQiJOyME

Another option would be to replace bridge with a plugin that is otherwise similar (perhaps it works by wrapping bridge) but also knows you want to set the MAC before calling the IPAM plugin. I don't know if anyone has coded that already.

what do you mean by "wrapping bridge"?

And also, would it not be possible to add an option to the bridge plugin that sets the mac address of the interface it creates? That would solve the issue instantly. @bboreham

[bboreham]

Wrapping bridge meaning a plugin that calls the code in the current bridge plugin.

And we won’t add the option into bridge because we’re trying to have a composable design. There would be a similar need in macvlan, flannel, etc., etc.

[xenorites]

Is there any roadmap for this? I am wanting to roll a new deployment that relies on a podman backend, but I need some services to be set to specific IPs; I currently use DHCP for IPAM.

Would it be possible to control the UID generated by the DHCP plugin? I think that would allow for more granular control, or at least provide reliable results.