I reported this bug on 10 Feb 2020 Case 04855962 it took a lot of wasted and un-chargable time to get this through the Meraki Support firewall with support insisting the MX64 was just following the RFC. Eventually after 7 hours of my own lab work they agreed with me and sent to development.
Meraki even closed the case and re-open a new one 04955618 which no one can explain to me (was this the keep the KPI's looking good ?
Months and months later still getting nowhere and I am sure there are other having this issue to and do not even know it due to the client fall back doing a new broadcast after getting no renewal response from MX64
I have written up a very detailed explanation on my blog for others to understand.
If other could please open cases if you suffer from this issue so meraki can get this fixed.
I did expect meraki to fix such a fundamental issue with DHCP quickly and other models may be effected to. I have ONLY tested the MX64.
Solved! Go to Solution.
I’m sad to say that a fix for this is probably not going to arrive any time soon. The amount of people doing DHCP relay to an MX has to be very, very low. These devices are targeted at a very specific customer-set and people doing DHCP relay to the MX itself are not likely to be very common. If this issue is a show-stopper in your environment just toss a dhcp-pool on the switch that’s doing you’re DHCP helper and call it a day.
@CharlieCrackle that bug should get fixed. I agree that it really shouldn't take that long to get something as fundamental as DHCP fixed.
I have not had your experience with Cisco TAC. I've reported several bugs and had bug IDs officially published. For the ones that get resolved, I find it typically takes 12 to 18 months. Many never get resolved.
More annoyingly, I've had Cisco Enterprise bugs I have logged and get fixed re-appear in newer products. The dumb arses must have copied older code and started using that for the new products. Very frustrating.
I feel pretty down on Cisco TAC over the last 24 months. I have had poor response times, and engineers that just don't seem to know their stuff and have to keep passing it onto other teams and acting as a go-between. I don't need message takers, I need engineers and problem solvers.
I've pretty much given up on Cisco Enterprise now.
Unfortunately, bug/defects like this are resolved in priority order. A bug that's 24 months old that is affecting one person will take a back seat to one that's brand new but is affecting dozens. That's just how it works, good, bad, or whatever. It works like this everywhere.
I have tested up to 15.29 and the stable release of 14.x I do not know other devices are effected as I do not have access to any others in this config. if the devices share code they may be.
The issue is it may be effecting other people and they do not even realize it. Anyone who has a WLAN controller on the network that is proxying the DHCP will be effected. It is just luck that most devices it seems when the DHCP renew fails (after 3 seconds) then go back to the broadcast for a new ip address technique. Most people would never know the renewal failed and the time that took as the device continues to work fine while this failure happens in the back ground.