DHCP sometimes ignores discover from Polycom phones

RouterOS General
1

New hap ax3. Upgraded to 7.22.1 & performed hard reset prior to first time configuration.

I’m new to ROS and am enjoying figuring this beast out, but while I’ve got everything else I need configured and working properly, one item is a head scratcher.

I have DHCP server setup on the router and working properly for all devices on my network (Win11, Ubuntu, phones/tablets, streaming media devices, cameras/video recorder, etc.) No VLAN, single class C IP segment, one router (this ax3,) no other DHCP servers on network. I have 3 Polycom VVX phones hard-wired on the network. When I reboot the phones 2 out of 3 times, it will receive a DHCP address and work flawlessly. Then about 1 out of 3, the phone will complain about no DHCP (but will indicate it is plugged into the network.) This happens on all 3 phones connected to different jacks/switches.

I have power cycled everything to ensure a clean startup with no old MAC/IP table artifacts.

I ran the internal packet sniffer capture and viewed through Wireshark with both successful and unsuccessful DHCP calls. With successful, I see the full back and forth as expected with DHCP (Discover, Offer, Request, ACK, life is grand.)

On the unsuccessful, all I see from the phones in the pcap log are the multiple DHCP discover attempts to the broadcast address with nary a peep from the DHCP server. A reboot of the phone most times will result in a successful DHCP address assignment. This is reproduceable.

I enabled DHCP logging on the router and reviewed. During successful DHCP calls, I see the interaction from the DHCP server. During unsuccessful calls, DHCP just sits there like it never received the discover broadcast.

Firewall rules are all defconf/out of the box. I even enabled logging and see the traffic is allowed to pass through.

Any generic thoughts I might focus on? I’m a pretty astute IT guy, so I think I’ve been able to determine that either the DHCP server ignores the discover packets or the packets are somehow being blocked from getting to the DHCP server.

Jack

2

Just a thought: recently ROS DHCP server started to be picky about DHCP discovers received and if it thinks those discovers are invalid, it will ignore them. In particular some (not very valid) options included in discovers are problematic. So when the problem appears next time, capture DHCP discovers ... and compare those (field by field) to DHCP discovers which do get a response from MT DHCP server. I'd be interested to hear back what changes ...

3

I saw a similar thread on this idea…something about DHCP clients not providing an Option 255-End. Unfortunately, the failed DHCP discover packets do have this option.

I do appear to be onto something though: the failed DHCP attempts include 802.1Q (VLAN) in the packet. I read the Polycom firmware attempts to determine the VLAN through its own auto-discovery process and include that in the packet. The discover packet indicates a VLAN ID: 1 (whether this is obtained from the router or this is a default if no VLAN is identified is unknown.) I have no VLANs defined on the router bridge interface. I found a way to disable all the VLAN discovery on my test phone, and after 6 reboots, all attempts to obtain an IP address via DHCP were successful.

I do see in successful DHCP discover packets, no mention of VLAN is included.

So it seems possibly the DHCP server is ignoring the packet because of the default VLAN ID 1 being included.

4

Good diagnosis. The Polycom phones use Cisco CDP/LLDP-style VLAN auto-discovery and send their DHCP Discover frames tagged with VLAN ID 1 by default when they cannot detect a voice VLAN via CDP/LLDP. RouterOS DHCP server bound to the bridge interface drops these tagged frames when the bridge does not have VLAN filtering enabled with VLAN 1 properly configured.

If you want a RouterOS-side fix that does not require touching each phone, enable bridge VLAN filtering and add VLAN 1 to the bridge VLAN table with the Polycom ports as untagged members:

/interface bridge set \[find name=bridge\] vlan-filtering=yes
/interface bridge vlan add bridge=bridge tagged=bridge vids=1
/interface bridge port set \[find interface=ether2\] pvid=1

(Adjust interface names to match your config. pvid=1 is the default so that line may already be set, but the VLAN table entry is what allows tagged VLAN 1 ingress to be treated as native and passed to the DHCP server.)

Alternatively, on the Polycom side, disabling CDP/LLDP VLAN discovery under Settings > Network > Ethernet > VLAN is the simpler fix for a flat non-VLAN network since the phones have no reason to be tagging anything in that setup.

5

Good detective work tracking that down. The core issue is that MikroTik's DHCP server listens on the bridge interface and expects untagged frames. When Polycom phones send DHCP Discover with an 802.1Q tag (VLAN ID 1) the packet arrives as a tagged frame on the bridge, and RouterOS DHCP server doesn't process it because it's sitting on the untagged side.

The Polycom CDP/LLDP-MED VLAN discovery is the culprit -- it probes for a voice VLAN, gets no response (since you have no VLAN configured), then falls back to VLAN ID 1 as a default and tags its DHCP discovers with it.

Disabling VLAN discovery on the phones is the cleanest fix for your setup. If you ever need to run VLANs later, the alternative is to enable bridge VLAN filtering and explicitly configure VLAN 1 as an untagged member on the relevant bridge ports -- that way tagged VLAN 1 frames get properly processed. But since you have a flat network, phone-side VLAN discovery off is the right call here.

6

Thank you for the confirmation to my observations. I left RouterOS unadulterated for VLAN config and simply set the phones to disable CDP/LLDP. If I had a larger environment, the alternative config of using VLAN 1 may have been necessary.

Thanks again!