DHCP problem with laptops

[rmoneal]

I have a strange one. I have 3750s and 2950s in varies buildings all config'd with user ports access mode and trunked to a 3750 (dist layer)in each building. We have dhcp servers on each vlan to issue ip addresses for those segments. This problem doesn't happen on desktop pcs only laptops they sometimes don't get ip addresses from the dhcp server, they default to the 169.254.-.-. With a sniffer I see the dhcp discovery packet leave the clients pc but when I snif the 3750 (dist layer) port that connectsto the access layer 3750 I don't see the packet.

[Richard Burts]

Rod

Do you have the switch ports configured with port fast? One scenario which could produce the results that you describe is that switch ports are doing the standard spanning tree behavior of blocking, listening, learning, forwarding. Until the port gets to the forwarding state it can not forward frames received from the device. If the laptop is booting it will activate its Ethernet and send DHCP requests. If the switch port is not yet in forwarding state the DHCP will not be forwarded. It is possible that the PC has tried, retried, and quit before the switch port gets to the forwarding state. Port fast on the switch port will solve this scenario.

HTH

Rick

[rmoneal]

Thanks for the response and yes portfast is enabled. Another twist is if this user takes his laptop to another port even on the same switch it will get an address and moves back to his port and it works. One thing I did see on the trace is the Bootp flags:0x0000 (unicast). On a working pc the Bootp flags:0x8000 (broadcast).

[glen.grant]

If the servers are on the same vlans then the problem is either the client or the dhcp server . The first packet out dhcpdiscover should be the broadcast and the server should reply .

[rmoneal]

I think the client because the the dhcp server is not seeing the request. Here's a trace at the client end the field Bootp flags: 0x0000 (Unicast) is what I'm confused about:

No. Time Source Destination Protocol Info

1 0.000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xe19a6a20

Frame 1 (343 bytes on wire, 343 bytes captured)

Arrival Time: Feb 27, 2007 09:15:45.577231999

Time delta from previous packet: 0.000000000 seconds

Time since reference or first frame: 0.000000000 seconds

Frame Number: 1

Packet Length: 343 bytes

Capture Length: 343 bytes

Protocols in frame: eth:ip:udp:bootp

Coloring Rule Name: UDP

Coloring Rule String: udp

Ethernet II, Src: 00:18:8b:a6:07:d4 (00:18:8b:a6:07:d4), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Destination: Broadcast (ff:ff:ff:ff:ff:ff)

Address: Broadcast (ff:ff:ff:ff:ff:ff)

.... ...1 .... .... .... .... = Multicast: This is a MULTICAST frame

.... ..1. .... .... .... .... = Locally Administrated Address: This is NOT a factory default address

Source: 00:18:8b:a6:07:d4 (00:18:8b:a6:07:d4)

Address: 00:18:8b:a6:07:d4 (00:18:8b:a6:07:d4)

.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame

.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address

Type: IP (0x0800)

Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 329

Identification: 0x09be (2494)

Flags: 0x00

0... = Reserved bit: Not set

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 128

Protocol: UDP (0x11)

Header checksum: 0x2fe7 [correct]

Good: True

Bad : False

Source: 0.0.0.0 (0.0.0.0)

Destination: 255.255.255.255 (255.255.255.255)

User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)

Source port: bootpc (68)

Destination port: bootps (67)

Length: 309

Checksum: 0x6b7d [correct]

Bootstrap Protocol

Message type: Boot Request (1)

Hardware type: Ethernet

Hardware address length: 6

Hops: 0

Transaction ID: 0xe19a6a20

Seconds elapsed: 0

Bootp flags: 0x0000 (Unicast)

0... .... .... .... = Broadcast flag: Unicast

.000 0000 0000 0000 = Reserved flags: 0x0000

Client IP address: 0.0.0.0 (0.0.0.0)

Your (client) IP address: 0.0.0.0 (0.0.0.0)

Next server IP address: 0.0.0.0 (0.0.0.0)

Relay agent IP address: 0.0.0.0 (0.0.0.0)

Client MAC address: 00:18:8b:a6:07:d4 (00:18:8b:a6:07:d4)

Server host name not given

Boot file name not given

Magic cookie: (OK)

Option 53: DHCP Message Type = DHCP Discover

Option 116: DHCP Auto-Configuration (1 bytes)

Option 61: Client identifier

Hardware type: Ethernet

Client MAC address: 00:18:8b:a6:07:d4 (00:18:8b:a6:07:d4)

Option 50: Requested IP Address = 169.254.136.184

Option 12: Host Name = "usmtn-mascha-l"

Option 60: Vendor class identifier

[sundar.palaniappan]

Hi,

DHCP Discover packets are broadcast packets and not unicast like what you see. Why does the laptop send a unicast packet and which device does it send the packet to?

Match your sniffer trace with the trace in the link below and any discrepancy at stage 1 would indicate a problem with the host/laptop configuration.

http://cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a00800f0804.shtml#sniffertraces

HTH

Sundar

[sundar.palaniappan]

Option 50: Requested IP Address = 169.254.136.184 --> Why does the laptop request this address from the DHCP server?

[rmoneal]

I don't know why the laptop sends a unicast.

The client connects to a 3750.

[schcandy1]

Rick,

802.1d spanning tree has been operating fine for ages with PCs and laptops(no portfast).

We are seeing the same problem with our laptops lately. A manual release / renew has been necessary to get laptops an IP.

Enabling portfast appears only to be a work around and not addressing the real issue.

Something with the NIC drivers, stack init on the laptops appears to be the real issue. Since PCs are still working fine without portfast it seems that the laptops are the source of the issue. We can't enable portfast in our environment as mobile users generally tend to be the same people who cause L2 loops plugging in unauthorized gear, etc. Anyone else see the same?

[Richard Burts]

Andrew

I think that you are suggesting that the basic issue is something in the stack on the laptops. I would agree with that. If you can identify that issue and fix it, then that is the optimum solution.

But if that solution is difficult (or impossible) then port fast may represent a work-around. If I understand your post correctly you have laptops that do not get an IP address when they bootup but that do get an IP address if you subsequently do a release and then a renew. That certainly suggests to me that there is a timing issue and that portfast could be a work-around. If policy in your environment dictates that you not use portfast, then you need to find some different solution.

HTH

Rick

[rmoneal]

I have portfast enabled. Even after the pc boots up and doesn't get an ip address, I'm still unable to get an ip address doing the release and renew. What's strange is they can sometimes go to another connection, plug in and get an ip address then go back to their original connection and then work fine and the other connection is on the same switch just a different port.

[glen.grant]

It has always been reccomended to have portfast turned turn eliminate bootup dhcp and other problems like IPX pulling address . If for some reason the pc does not activate the nic until very late in the boot process and portfast is not turned on then the pc will be booted and trying to pull an address but spanning tree will be running for approx. 50 seconds without portfast on , during this time the pc will time out and assign itself a microsoft assigned address of 169.x.x.x which is normal if it cant pull an address from the server . Portfast will eliminate this type of problem . Are the laptops doing this , I don't know . Portfast does not shut off spanning tree it just eliminates a couple of the learning states . We always use portfast and will still prevent loops if someones plugs some rogue in or introduces a loop , we see it all the time .

[rduke]

I have had a number of new computers come in from Dell that had 802.1x enabled out of the box. Most of them worked OK, but a few had some goofy problems until I turned it off. I am curious if anyone else has seen this.

Randy

[Lazarus G]

I seem to have a similair problem on c3560v2 and c3750v2 switches. However my laptops are connected via HIPT phones and captures on the access switch trunk show server responses to the client request and discover packets in the correct VLAN. DHCP snooping debugs show the switch knows the correct output interface to reach the client. Captures SPANNED from the affected interface show no server responses - only client packets (request and discover). Issue is resolved by rebooting phone (which bounces switch interface.) phone works ok, workstations arent affected only tablet PCs and laptops.Have removed all config except voice and access vlan speed and duplex settings with fault remaining. Changing access vlan doesnt clear fault either.

I also noticed unicast flags in DHCP discover packets with detsination address ff:ff:ff:ff:ff:ff/255.255.255.255 and ciaddr of 0.0.0.0. The following links explain that the client can set the broadcast or unicast flag to tell the server how it wants to receive the response;

http://www.askdavetaylor.com/dhcp_unicast_broadcast_flag.html

http://www.tcpipguide.com/free/t_BOOTPDetailedOperation.htm

Not sure why client request a unicast response if it has no IP address though...but it does seem to be commonplace in captures ive done and those on the web..off to read the rfc

...................................................

looks like these paragraphs of RFC2131 are quite informative;

"

   A client that cannot receive unicast IP datagrams until its protocol
   software has been configured with an IP address SHOULD set the
   BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
   DHCPREQUEST messages that client sends.  The BROADCAST bit will
   provide a hint to the DHCP server and BOOTP relay agent to broadcast
   any messages to the client on the client's subnet.  A client that can
   receive unicast IP datagrams before its protocol software has been
   configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
   clarifications document discusses the ramifications of the use of the
   BROADCAST bit [21].
   A server or relay agent sending or relaying a DHCP message directly
   to a DHCP client (i.e., not to a relay agent specified in the
   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
   an IP broadcast using an IP broadcast address (preferably 0xffffffff)
   as the IP destination address and the link-layer broadcast address as
   the link-layer destination address.  If the BROADCAST bit is cleared
   to 0, the message SHOULD be sent as an IP unicast to the IP address
   specified in the 'yiaddr' field and the link-layer address specified
   in the 'chaddr' field.  If unicasting is not possible, the message
   MAY be sent as an IP broadcast using an IP broadcast address
   (preferably 0xffffffff) as the IP destination address and the link-
   layer broadcast address as the link-layer destination address.

"

in the captures the unicast flags are set to zero.

...........................

Have reviewed some captures the one I attached shows three transaction ids

1) client has the lease from different subnet and is suggesting it to be used (option 50) - beleive it should receive a NACK from the server (but doesnt). Bootp flag set to unicast. txid: 0x61d9bea3

2) client drops the option 50 and is just sending DHCP discovers with no ciaddr value, however bootp flag still set to unicast (so it cant get a response?!?!) txid: 0X2c4aacb3

3) what id expect from a DHCP discover, no ciaddr, bootp flag is set to Broadcast - so client can receive response despite it not having an ip address: txid: 0x2757c87d

These three transactions take place between 1209hrs and 1212hrs.

The client never receives a response.
Guess the implication of the RFC is that the server works out that the client cant receive the offer (point 2) and elects to respond with a broadcast even if the discover is set for unicast (??)

Still not certain of the implication but will pursue...