Failure with Proxmox VM DHCP and Mikrotik CRS326-24S+2Q+

I am currently debugging a strange behaviour with a newly set-up configuration using Proxmox VE. In the same environment VMs with xcp-ng are working well, despite this looking like pointing at Proxmox, I believe the the switch being at fault / misconfigured.

I appreciate any support leading me to resolve this issue.

DHCP requests emerge from a VM in Proxmox on a tap device.
The tap is connected to a vmbr device backed by a LACP bond on the Proxmox host.
The two LACP legs are switched to identically configured ports at the CRS326-24S+2Q+ and are properly identified as LAG by SwOS.

According to packet capture on the Proxmox host, the DHCP requests properly go out on the bond0 interface.
According to a custom ACL rule on the switch, the packet counter is hit with the following filter criteria:

  • MAC of the VM
  • VLAN not present (it is using the default VLAN)
  • IP DST: 255.255.255.255
  • Protocol: 17

The MAC of VM appears with the proper VLAN identifier in the Hosts list of the switch.

Despite these packets being broadcast packets, they are not distributed to the other ports of the switch.
I am at odds why these packets are not being flooded onto the other ports.
At the same time IP6 packets originating from the same VM are properly distributed by the switch.
Also this is only happening with DHCP, if I set the VM to static address, everything works flawless.

When setting up Forwarding I could obtain the actual packets on an unused interface:

  • Mirror Egress on both ports of the LAG
  • Mirror to unused port on a different machine
  • tcpdump -s 65535 -w pmx.pcap -i igb0 -T carp ether host bc:24:11:29:c4:3b
Frame 1: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Jul 20, 2025 10:32:22.949117000 CEST
    UTC Arrival Time: Jul 20, 2025 08:32:22.949117000 UTC
    Epoch Arrival Time: 1753000342.949117000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 342 bytes (2736 bits)
    Capture Length: 342 bytes (2736 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:dhcp]
Ethernet II, Src: ProxmoxServe_29:c4:3b (bc:24:11:29:c4:3b), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
    Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: ProxmoxServe_29:c4:3b (bc:24:11:29:c4:3b)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
    [Stream index: 0]
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 328
    Identification: 0x0000 (0)
    000. .... = Flags: 0x0
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: UDP (17)
    Header Checksum: 0x79a6 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 0.0.0.0
    Destination Address: 255.255.255.255
    [Stream index: 0]
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 308
    Checksum: 0x417c [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Stream Packet Number: 1]
    [Timestamps]
        [Time since first frame: 0.000000000 seconds]
        [Time since previous frame: 0.000000000 seconds]
    UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x19605a64
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: ProxmoxServe_29:c4:3b (bc:24:11:29:c4:3b)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        Length: 1
        DHCP: Discover (1)
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 576
    Option: (55) Parameter Request List
        Length: 7
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (12) Host Name
        Parameter Request List Item: (15) Domain Name
        Parameter Request List Item: (28) Broadcast Address
        Parameter Request List Item: (42) Network Time Protocol Servers
    Option: (12) Host Name
        Length: 9
        Host Name: localhost
    Option: (60) Vendor class identifier
        Length: 12
        Vendor class identifier: udhcp 1.37.0
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: ProxmoxServe_29:c4:3b (bc:24:11:29:c4:3b)
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000

Update:
The issue is with the LACP LAG behind which the DHCP server is.

If I force one of the links of the LAG down all packets are properly broadcast to the remaining port of DHCP server.
I tested with both links independently and it works if one of them is down. It does not work if they are both up and the LACP LAG is bonded.

If I had to guess, the problem is that despite the underlying ports being trusted, the bond “port” is not set as trusted.

To summarize:
IP4 DHCP REQUEST broadcast packets are not forwarded by the switch to LACP LAG ports.
I consider this a severe bug.

Received a relatively fast answer from Mikrotik support on 7/31:

We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming SwOS versions, unfortunately, I cannot provide a release date now.

Possible workarounds:

  1. Enable “Trusted Ports” on all switch ports and disable the “Add Information Option”.
  2. Use switch with RouterOS.

Workaround 1 works.
Workaround 2 is missing the point.