Packet capture DHCP relay on SG300?

[dmackerracher]

Hi, 

I'm trying to diagnose what is potentially a DHCP relay issue on an SG300. I have a client with one deployed with 3 VLAN's. Windows 2008 R2 DHCP server is providing addresses for all 3 VLAN's. Everything is working as expected except for Linux machines. On 2 of the VLAN's, any Linux machines (includes embedded linux e.g. in printers) are heavily delayed in receiving an IP address from the DHCP server. They do arrive eventually but can be over an hour later. The other VLAN contains the DHCP server and it has no problem handing out IP's to Linux clients (isn't operating DHCP relay for that VLAN).

I've been running wireshark at a client and on the DHCP server, but its hard to see what is actually happening. Since the DHCP relay requests come from the switch rather than the client, its hard to identify discovers as they are made.

I'm wondering if there is an easy way of doing packet captures at the SG300 to try and identify the DHCP traffic and see whether the issue is with the switch or at the DHCP server.

Thanks, 

Donald.

[Aleksandra Dargiel]

Hi Donald,

You may use port mirroring on the switch which would just copy traffic from one port to another but this is only working for one port at the time.

However first of all I would suggest you to ensure you are running the latest firmware and boot code on the SG300: firmware 1.4.0.88 and boot 1.3.5.06

with the packet capture it would be a good idea to contact Cisco Small Business Support team and open ticket so they can go with you through all details and analyze the root cause:

http://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html

Regards,

Aleksandra

[dmackerracher]

I'm planning on upgrading both firmware and boot code on it (hopefully this weekend). I don't suppose you have heard of anything like this happening in DHCP relay on the SG300? It's odd that everything is fine for Windows clients, just not Linux clients.

Thanks, 
Donald.

[dmackerracher]

SG300 is now on firmware 1.4.0.88 and bootcode 1.3.5.06

I'm seeing a couple of other issues now as well with this switch and another SG200 that is connected to it.

The SG300 is throwing out %ARP-E-ARPTBL: ARP Table Overflow, aggregated pretty frequently.

TCAM is currently set at default. I'm periodically losing packets to the SG200 that is connected to it, but not other switches connected to it.

What can I look at in terms of diagnostic information to try and trace what's going on?

Thanks,

Donald.

[Aleksandra Dargiel]

Hi Donald,

You can take a look at he show tech-support output. But we may also need report this to the engineering team for more detailed diagnostic.

I would suggest you to open ticket in this circumstances.

Regards,

Aleksandra

[dmackerracher]

I don't think I can open a ticket - don't have a support contract with Cisco.

I'm wondering if my problem is related to this thread: https://supportforums.cisco.com/discussion/12306761/firmware-14088-sg300-52-appears-break-dhcp-relay

The TCAM on the SG300 is set at default of 128, but I have over 200 hosts on the network. Would this explain why I see dropped packets to places intermittently that have no problems with their actual physical connectivity? This also probably explains why I'm not seeing it in my test environment either.

Any rules on what to set the TCAM to? Just aim for a figure higher than the number of hosts, ACL's, routes etc?

Thanks, 

Donald.

[dmackerracher]

Well, changing TCAM has sorted it. Raised the setting on the production SG300 and our network traffic has flattened out again and we have normal timings on DHCP relay allocation for non-windows machines as well.

Donald.