Cisco really needs to do something about this since if you create a static bind using a MAC address the device generally doesn't receive the assigned IP but if you enter the client ID instead it will. I don't know if the switch just doesn't check the static MAC table when receiving a request that uses the client ID but it should. If it receives a request it should check both tables and if it's not in the client ID table and it received a client ID it should strip off the leading byte and then check the MAC table or maybe when you create a static entry using MACs automatically populate the client ID table assuming a leading 01 unless manually over written.
On any dumb switch or router if I enter the client's MAC it will receive the address I designated but these switches don't. Fix it!
the fact is if the DHCP Discovery or request come with client ID the MAC address is not checked. and if the client ID is not valid the first available address from the pool is given despite the fact that MAC address binding was created. To workaround this you might:
1. first,delete the static host of the devices to make them get IP address by DHCP.
2. Then,see the devices recognized as client ID or mac by DHCP
3. Then,configure the devices in the static host and configure the client ID or mac just according to the DHCP they gets.
4. Last,clear the DHCP binding table and reboot all the devices.
It is true that this is not the same on many other devices thus the engineering team is looking into.
I would recommend you to contact Support Center and open ticket: http://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html
Thanks for the response. I know how to deal with it but it's a real PITA and it simply shouldn't be this complicated. This has to be a bug cuz if it operates the way it was intended then Cisco got some real idiots on the SMB engineering team.
Here may be a useful post.
This feature does work unless it became broken on the latest releases.
I appreciate your determination however can we be more specific on this. Can you provide us with packet capture of what client is sending in DHCP discovery or DHCP request, what switch is sending id DHCP offer and how the DHCP binding is showing on the switch vs how it is configured.
In your first response in this thread didn't you acknowledge what I'm complaining about to be the actual way the switch operates so why would I need to provide a packet trace or wireshark intercept if you know it does what I say it does. All I'm saying is that what is does is stupid and if I put a mac in the bind table and the host initates a dhcp request with a client id it should still recieve the intended ip because the switch should be smart enough to taked what it's given either mac or client id by simply ignoring the first byte if the string length is over six bytes, simple.
What format should MAC/client ID be in? The switch only allows me to add the address without the "."'s but when I reboot the client, I get some strange IP not in my pool. I'm running the latest August firmware on my SG300-20.
I'm ready to give up. I added the static entry with the client ID and everything looks correct on the switch config. But, when I reboot the client, I get a completely unrelated IP (not an IP even close to what I entered), no default gateway and incorrect mask. The mask should be 255.255.255.0, I get 255.255.0.0.
you might need to look into packet capture to see what exactly is sent. there can be some difficulties with client ID but incorrect mask and no default gateway it could be related to the configuration error.
I would suggest you to open ticket with small business support team so they can work with you on it:
This issue still available in Cisco SG-300 DHCP server. first let the switch decide the option to use (Client identifier or MAC). then use that option to create static host binding. also do not type anything in to 'client name' field. in my test DHCP not worked when any value added in to client name.
Yes that's the way it has to be done but a real PITA especially if you're upgrading a switch and not just starting from scratch. On any other switch if you copy your bind table and migrate to an SG there's a could possibility that some maybe most won't be assigned an IP because you entered the MAC and they responded with a client ID. If the device responds with the extra byte for the client identifier it should first check it's client ID table and if it doesn't find anything, strip the first byte and compare strings in the MAC table. Maybe just forget the client ID all together and allow us to turn off that option since client IDs are an option whereas the MAC is not it is mandatory in the dhcp request and I believe devices with client IDs still have to respond with a MAC as well so what's the point?