First DHCP Discover frame lost, WS-C3560CG-8PC-S and HP laptop or desktop

[vladakoci]

We seem to have an issue with HP laptops and desktops connected to Cisco WS-C3560CG-8PC-S.

First DHCP Discover  frame is lost 90% times ( sometimes it works ). I am also testing with PXE boot ( BIOS ), so even before the operating system starts. The symptom is that the first DHCP Discover  frame  arrives to the PC port on the switch, but is not switched to the uplink port, and there is no answer from the DHCP server then. The second DHCP Discover  frame is always processed succesfully, but it takes 3-5 seconds until PXE boot or operating system sends it out. I am using monitor session and another machine with Wireshark to capture the traffic on the PC port and uplink port.

This is the same for PXE boot and for the phase when operating system ( Windows 7 ) starts.
I am trying another piece of HW, which is Shuttle with Ubuntu, and this one always works fine, means the very first DHCP discover frame is always properly switched to the uplink and the Linux machine gets a DHCP address immediately.

I am trying  c3560c405ex-universalk9-mz.150-2.SE5.bin and the most recent c3560c405ex-universalk9-mz.150-2.SE8.bin images, but both the same.I started with our standard port config, which is full of features (switchport security, ARP inspection, DHCP snooping etc.), removed them one by one, but did not help. Now I have a very simple port config

!
interface GigabitEthernet0/1
 switchport access vlan 5
 switchport mode access
 switchport nonegotiate
 spanning-tree portfast
!

I tried many things, removed CDP, LLDP. inline power, played with speed/duplex, flowcontrol, used spanning-tree bpdufilter enable and many others, but nothing helped. Tried to debug, but do not see anything suspicious.

If anyone has an idea what could be a cause please let me know.

Thanks,
Vlad

[vladakoci]

Today I  tried WS-C3560CG-8PC-S with c3560c405ex-universalk9-mz.152-2.E3.bin, this has not helped.

I tried WS-C3560CX-12PC-S and 15.2(3)E  with exactly the same config and this one works perfectly fine.

Seems like a bug on WS-C3560CG-8PC-S.

[Peter Paluch]

Vlad,

It may well be a bug but with a very basic configuration of your switch and its ports, I doubt it - the propagation of frames across a switch is not controlled by IOS, rather, it is handled entirely in hardware.

What I am suspecting is that perhaps the HP laptops/desktops have a tendency to flap the NIC connectivity very closely around sending the DHCP/PXE request. This would cause the port on the switch to renegotiate the link, and till it comes up again, received frames are dropped. You have said yourself that the Shuttle connected to the same switch does not exhibit any issues.

You could try lowering the carrier-delay on interfaces to an extremely short value just to test things out, but I doubt it will help. At the same time, while perhaps a minor inconvenience, this behavior is not a show stopper - or is it?

Best regards,
Peter

[vladakoci]

Hello Peter,

Many thanks for your valuable inputs.

By a bug I mean both, SW ( code ) and HW ( design ) bugs as I have experience with both :)

Yes, it is obvious this is something on the physicial layer. I have tried many things, also changed carrier-delay, but did not get anything that would improve.

For me as a networker this issue should not be a big deal. PXE boot for sure works, it adds just a little delay. With Windows this seems it might cause troubles. As we have now very fast laptops with SSD a user might logon before the network is up and might get troubles with Windows shares or other things then. These issues were reported, but I have never seen or experience it by myself. There might be also a link to how Windows ( AD etc. ) parameters are set.

We've reported this to our Cisco partner and maybe it will be wise to report also to HP even if we know some other switch platforms do not have this behaviour.

Thanks,
Vlad

[vladakoci · Accepted solution]

I opened a TAC case and after some time got an answer:

=============

Upon researching I have learnt that this issue expected an cause due to a different generation of PHY being used in Switch and the Laptop.

PHY’s used on the Laptop are more recent when compare to the PHY’s of a switch, causes functional differences especially when it comes to link up event and ready to transmit/receive the traffic

Thus, the Discover packet is being lost at the switch PHY when it was not in ready state to accept the traffic, though the link negotiation is already performed and is up.

The BOOTP frame is a very first frame generated by the laptop and is quick as soon as the link is up, but when it is transmitted across the port, at the other end the switch is not forwarding the traffic.

However, the subsequent BOOTP Discover frame is switched as expected due to the fact that the PHY at the switch side was side by the time

This behavior should not cause any disruption to the user traffic, as it is most likely to drop the very first packet, the other functionally of the PHY’s remain same be it a recent or old generation

I am afraid, there would not be any enhancements to this behavior at the hardware level as well as software tweaking. The behavior is expected in such special scenarios.

=============

[Peter Paluch]

Hi Vlad,

Thank you for getting back to this thread and sharing the information!

It is a bug, after all... a bug in hardware. I wouldn't have thought that similar interoperability issues can happen in 2016. Still, the issue is at hand.

Thanks again!

Best regards,
Peter