I have an SG500 switch that I'm using in L3 mode and trying to set up a few different VLANs for different things. I'm trying to use the switch to function as a DHCP server on those VLANs and it seems to be working properly. However, i have one VLAN that has an external DHCP server and have not configured a pool for that range. However, clients that plug into that VLAN get a DHCP NAK from the switch when the try to pull an address (in addition to the OFFER they get from the legitmate DHCP server) and this really fouls things up. Is there any way to prevent the switch from sending a DHCP NAK on this VLAN? Removing the interface IP from this VLAN isn't an option as it's the way out for all the other VLANs.
Solved! Go to Solution.
When can we expect the update that will resolve this? The thread is 10 months old now, and the bug was logged into the system 8 months ago. This is very frustrating.
Any word on version 1.4.1? I'd really like to get this issue resolved. We're getting close to a year on this issue. It's very frustrating that an advertised feature doesn't work properly and that the fix is taking so long.
It's now been a year since I first reported this issue, and that's an awfully long time to wait for a DHCP server that works properly. When can I expect to see a release version of 1.4.1?!
1.4.1 firmware has been released on 8th of May and should address DHCP issues. Please feel free to comment if you tested.
Thanks. Any chance that we see the full release notes soon? I like to read them before I install any updates. I'm somewhat frustrated that they weren't made available at the same time as the firmware.
Hello Mr Tatton,
I apologize for the long delay. I can confirm we have recreated this issue here in our lab. We do see the NAK, but it never causes any issues for the PCs here.
I am checking with the engineering and escalation teams on if this is even supposed to be happening, and will update you when I hear something back.
You are of course also welcome to give us a call at the SBSC and we can create a support case for you. Sometimes having a case number speeds things up a bit.
Christopher Ebert - Advanced Network Support Engineer
Cisco Small Business Support Center
I did also figure out that if you disable the IP interface for the VLAN that NAK will never get sent. I cannot tell from your diagram however if the switch is doing the routing for VLAN 1, so I understand that may not be an option for you.
Unfortunately the switch is doing the routing between VLANs 33 and 50 so disabling the IP interface it not an option.
RFC2131 says that if the client receives a DHCPNAK it has to start the DHCP process all over again. I don't know why your clients don't have an issue with it. Perhaps it's timing and your clients complete the process before the switch sends the NAK. Either way, it's not a DHCP server on that segment and shouldn't send anything at all.
Hello Mr Tatton,
We have opened a new bug on this issue, CSCup71464. Bugs tend to get more attention the more cases that are attached to them, so if you would like go ahead and give us a call so we can create you a case and push this along. Engineering may be able to provide you a beta image that fixes this, although since the bug was just created I don't think they have a fix yet.
I don't think there is a way for customers to access the bug database, at least not one I've ever seen. You can signup to be notified about new firmware versions, and then check the release notes for what got fixed, although I understand that isn't ideal.
Your other option is to get a support case opened that we can escalate and attach to the bug. Then you would interact with L2 directly, and they may be able to give you a beta or engineering image before the fix gets implemented into a firmware release.
I noticed that there was a new firmware version posted last week but it didn't appear to mention anything addressing this issue. Can you check into the status of the bug report for me? Thank you.