DHCP Scopes on SG500

[christopher.tatton]

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.

[chrebert]

Hello Christopher,

Was the client in question a member of another VLAN before being moved to the new one? 

You mentioned the DHCP NAK causes some issues, but you don't specify what.  I was just testing with clients in different VLANs for another case, and I usually saw a NAK when I switched from one to the other, but it didn't cause any problems, so I am wondering what is getting fouled up?

Christopher Ebert - Advanced Network Support Engineer

Cisco Small Business Support Center

[christopher.tatton]

No, the client was a member of the same VLAN.  The issue seems to be that when the Windows client tries to renew/obtain an address, it gets a NAK from the switch immediately because there is no scope configured for that subnet.  It does get a response from the correct DHCP server as well, but it still seems to cause an error and I get the wonderful error message below:

"An Error occurred while renewing interface Local Area Connection : The name spacified in the network control block <NCB> is in use on a remote adapter.
The NCB is the data" 

I would think that if there is no DHCP scope configured for that VLAN on the switch that the server should remain silent.

A little background on my setup and what I'm trying to accomplish:

Everything works fine except that clients attached to VLAN 33 get a DHCP response from the switch (that is always a NAK because there's no pool configured for that VLAN).  I tried using DHCP relay, but I can't configure relay and have the DHCP server in the switch on at the same time.

[chrebert]

Hello Christopher,

Thank you for the diagram, makes things much easier to understand.

I have setup an SG500 here in my lab to recreate your topology.  Mine is pretty much exactly like yours.  SG500 as DHCP server for VLAN 50, and then an outside DHCP server on 33 and 1.  

I put a host in each VLAN to make sure the SVIs were up.  The only pool configured is the same as yours, for VLAN 50.  I plugged another host into an access port for VLAN 33 and it picked up DHCP just fine.  There was a DHCP NAK from the switch, but it was after the process completed with the outside DHCP server.  The host had no problems.  Does the DHCP exchange with the outside DHCP server complete on the host?  

I did google a bit on that error message, and it looks like it mostly has to do with a stuck or misconfigured setting on the outside DHCP server, have you checked the log messages on it?

Christopher Ebert

[christopher.tatton]

When I was testing with wireshark, the client would see the NAK from the switch almost instantaneously and before anything else from the DHCP server.  The client would not complete the exchange with the outside DHCP server.

If I disable the DHCP server on the switch everything works fine.  The external DHCP server is an ISP provided/required router and I don't think it has much in the way of logging.  I wonder if it takes exception with another DHCP server on its networks and it's fouling things up.

However, should the switch still be sending out and response at all if there is no scope on that VLAN.  Shouldn't it just remain silent?

[chrebert]

I'll be honest I'm not sure if it should or shouldn't send out a NAK.  To me it seems like since it has nothing to do with DHCP in that VLAN it should just stay quiet, but some of the discussions I've seen make the NAK seem more important somehow, and not optional.

Since you mention the packet captures could you post them so I could take a look?  There may be something slightly different going on with your setup.  Your NAK being earlier might be having an effect.

You are of course welcome to open a support case and get that looked at, probably by level 2 if we can isolate it down to the switch.  Make sure to hang onto the pcaps and diagrams if you decide to do that, the more information the better.  However at this point I'm not sure it is the switch yet, since it seems to be normal behavior (the vagueness of NAK documentation aside) and it isn't causing any issues here in my lab.

Is it every client in that VLAN or just certain ones?  Is it possible to try with a different OS/version just to test?  It seems unlikely to make a difference, but you never know.

[christopher.tatton]

Here is the packet capture with the switch's DHCP server enabled.  You can see that the exchange starts normally, with a DISCOVER, OFFER, and REQUEST, but when the switch sees the REQUEST, it issues a NAK before the real DHCP server can issue its ACK.  This effectively ends the transaction according to RFC 2131.

I think the argument could be made that because there are no DHCP network pools valid for a particular VLAN, the switch is therefore *not* a DHCP server to that VLAN and should not act as one in any capacity and should remain silent to all requests.

As far as other OS/Versions, I only have Win 7 machines to test with, but I do have other devices that are not PC-based.  Their logging is pretty much non-existent, but I did notice when I was troubleshooting this that they are affected as well.

I tried to remedy this issue using ACLs but it appears that the SG-series switches only support inbound rules and not outbound rules, so I can't filter the messages from the switch itself.

[christopher.tatton]

Just wondering if there was any investigation done here.  I'd like to try and get the issue resolved.

Thanks.

[chrebert]

Hello Mr Tatton,

I just wanted to let you know we are still looking into this, and I hope to have a good answer for you sometime this week, although unfortunately I cannot guarantee that.  

Again if you are still under your tech support warranty you may want to open a support case, I usually have better luck pushing for an answer if I have a case number to go with it.

Christopher Ebert

[christopher.tatton]

Anything from Engineering last week?

[chrebert]

I did get a response letting me know it had been assigned to an L2 engineer, but the first thing they asked me was about a case number.  I will keep on top of this and see if I can push this along.

[christopher.tatton]

Any chance that I could get a little investigation to this issue?  It doesn't seem like this feature is working properly.

[joshuavijsma]

Hi,

I just wanted to confirm that this bug is affecting us too. Because of the DHCP NAK packets, our Yealink T41p VoIP phones are not able to provision themselves. Removed the SG300 switches from the network and all works fine. Bug is still present running the latest firmware at time of writing. It's very disappointing to see that a new firmware release is promised but never made available...

Greetings,

Joshua Vijsma

[jialbert]

Hi Joshua,

Thanks for your information.

This case happened after the new release of 1.4.0.

We will include that fix in next release 1.4.1.

Current workaround is the option 3 at attachment in my reply above.

The idea is to configure a non-allocatable DHCP host pool for the vlan to prevent any allocation 

Ip dhcp server

Ip dhcp pool host 33

Add 192.168.33.1 /24 hardware 0000.0000.0001 // use some mac that will never present in your network.

[christopher.tatton]

Considering the thread itself is 7 months old, and the Cisco bug tracking number is 6 months old, and firmware 1.4.0 is only 4 month old (exactly 4 months today I believe) to say that the case happened after the release of 1.4.0 is patently false.

The most frustrating this about this issue is that Cisco, arguably one of the most prestigious networking companies is the world, is unable to properly write and test the DHCP server in their switches to makes sure they meet standards while kids living in their parent's basement are capable of doing so.