MX64 DHCP Server does not respond correctly to relay agent flags suboption UNICAST

[CharlieCrackle]

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.

https://blog.cie.net.au/2020/05/dhcp-relay-issue-meraki-mx64.html

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.

[NolanHerring]

Great blog post @CharlieCrackle

Stumbled across it on Twitter and just posted about it not realizing you already posted here lol (have since deleted my other post).

Do you know if this is specific to the 64 or any version MX?

[NolanHerring]

Also what about firmware versions? Was this on 14.40? What about 15.x ?

[CharlieCrackle]

I have tested up to 15.29 and issue still exists.

[Adam2104]

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. 

[PhilipDAth]

@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.

[Adam2104]

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.

[CharlieCrackle]

I have to agree with you, being in the Cisco IT industry for the past 30+ years Cisco TAC has certainly degraded in the last 24 months. In the good old days Cisco TAC was the GOLD standard for support. Nothing was too much trouble it was all about getting your issue fixed ASAP. These days Cisco is a machine I call it the "Cisco System" if your issue falls out of what the system supports you are in big trouble and you can waist hours and hours of unchangeable time making your issue fit the system. Cisco has lost the human/common sense element due to digitization of everything. The joke line "The computer says NO" is becoming more prevalent.

[CharlieCrackle]

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.

[CharlieCrackle]

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.

[CharlieCrackle · Accepted solution]

Update..  it has taken a while bit this issue has been fixed in MX 15.34