Solved

PXE DHCP issues

Posted on 2015-02-11
17
307 Views
Last Modified: 2015-02-23
We are using WDS to rollout desktop images through PXE. We have used this config successfully in the past.

We were required to reconfigure our Cisco switches for a new naming convention. We re-enabled port fast on the switch where the single port that we use for imaging desktops is located.

We have disabled PXE on all onboard NICS, unless imaging the computer, so as not to pollute and consume our DHCP scope with DHCP/BOOTP address assignments.

We PXE-enable the single NIC when imaging, so we know that's the only computer requesting DHCP/BOOTP.

Since reconfiguring the switches, we have been unable to image computers with WDS.

No error message is generated on the client. The client just basically times out, after multiple DHCP requests because of the multiple requests, the scope fills with BOOTP requests and since there are no addresses left in the scope, the client times out (see client screenshot PXE_Boot.jpg).

Running wireshark on the DHCP server and filtering for BOOTP by the client MAC address, you can see only discoveries, no offers or ACKs (see PXE BOOTP Issues.doc).


Can anyone assist?
PXE-Boot.jpg
PXE-BOOTP-issues.doc
0
Comment
Question by:DougInOttawa
  • 8
  • 5
  • 2
  • +2
17 Comments
 
LVL 26

Expert Comment

by:Predrag Jovic
ID: 40603714
Is on the same server DHCP and WDS?
Maybe this is the solution.
0
 

Author Comment

by:DougInOttawa
ID: 40603750
no, they are 2 seperate servers. The only thing that changed was the switch configurations, but we re-enabled the specific port we use for imaging with port fast. Previous to the switch reconfigs, it worked.
0
 
LVL 10

Expert Comment

by:tmoore1962
ID: 40603978
Double check your switch configuration for VLAN and Default gateway make sure those didn't change when you renamed the switch
0
 
LVL 26

Expert Comment

by:Predrag Jovic
ID: 40604020
Maybe some ACL is not properly configured?
0
 

Author Comment

by:DougInOttawa
ID: 40604489
I moved the client connection to the same switch as the server, to reduce the hops, but it still causes the same problems.

We do not employ VLANS, so all switches are VLAN1.

There are no ACLs on the switches, except for a single Access Control List which is assigned to an SNMP community.
0
 
LVL 16

Expert Comment

by:vivigatt
ID: 40606841
Double check spanning tree and portpast configuration on the switch.
Run wireshark on the DHCP server if you can and try to see if it gets DHCPDISCOVER messages
If you are using only 1 (V)LAN, I guess that there are no issues with routing DHCP packets, but you may want to doublecheck that too.
One thing that intrigues me is that it seems that IP addresses are consumed in the scope. It may indicate that the DHCPDISCOVER packets are received by the server but that it does not send the corresponding DHCPOFFER packets. If the server has several NICs, make sure that DHCP Server is bound to all the NICs or, at least, to the correct one.  Check firewall config too.
DHCP sequence is basically described here :
https://www.h3c.com/portal/Technical_Support___Documents/Technical_Documents/Switches/H3C_S3610%5BS5510%5D_Series_Switches/Configuration/Operation_Manual/H3C_S3610%5BS5510%5D_OM-Release_5303%28V1.01%29/200901/624575_1285_0.htm#_Toc191727098
0
 

Author Comment

by:DougInOttawa
ID: 40606878
Thanks for the info. You can actually watch the dots (.) after the MAC address when the PXE client is trying to get an address and simultaneously watch the addresses get consumed on the DHCP server. We also verified that the BOOTP addresses are only getting assigned to the client that we're trying to connect.

If you look at the doc that was posted, you can see the DHCPDISCOVERs through WireShark.

The server and the client are on the same switch, so broadcasts should never leave the switch, firewall config shouldn't be an issue and the client should receive the offers.

Interestingly, the Wireshark capture didn't show any DHCPOFFERS.

Our switches are Cisco Catalyst 3560G's
0
 
LVL 2

Expert Comment

by:UnHeardOf
ID: 40607242
Is your scope configured with the options mentioned in this article ?

http://support.microsoft.com/kb/259670

Do you have dhcp snooping enabled? Take a look at this article

http://packetpushers.net/five-things-to-know-about-dhcp-snooping/
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:DougInOttawa
ID: 40607953
The only scope option configured is option 66 to point to the WDS server as the Boot Server.

This scope config has not changed and worked prior to the switch reconfig (see the attached doc)



I am running IOS version 12.2. which, according to the Cisco Configuration Guide, lo and behold DOES have DHCP Snooping as a feature.We manually configured the switch, so DHCP Snooping is globally disabled by default and DHCP Snooping is not active until DHCP snooping is enabled on the VLAN (according to the documentation FROM Cisco).

The statistics show that there appears to be is no snooping since we did not enable it:

 Packets Forwarded                                     = 0
 Packets Dropped                                       = 0
 Packets Dropped From untrusted ports                  = 0
Scope-Options-in-my-DHCP-server.doc
0
 
LVL 2

Expert Comment

by:UnHeardOf
ID: 40608050
If the wds server sits in the same subnet you don't need to use option 66. I believe  The server will see the pxe attempt. Try removing it worse case it won't work and you'll be back to square one.
0
 
LVL 2

Expert Comment

by:UnHeardOf
ID: 40608073
Also run wireshark on the dhcp server to see if dhcp offers are being sent. At least then you know the server is sending them.
0
 
LVL 2

Expert Comment

by:UnHeardOf
ID: 40608301
0
 

Author Comment

by:DougInOttawa
ID: 40608517
IP Source Guard is disabled by default. It can only be enabled if DHCP snooping is enabled (according to the Cisco documentation).

Wireshark was originally run on the DHCP server and the capture only produced DHCPDiscoveries.

I have re-run wireshark on the DHCP server. existing DHCP clients are contacting the server with no issue and the server is issuing ACKs.

During the same capture, we rebooted the PXE client from the HP desktop. Enclosed is a screenshot of the capture.

Only discoveries were received by the server and the source address is 0.0.0.0. Would this not explain why the PXE client never gets an IP, because the source address is 0.0.0.0?
Latest-Wireshark-Capture.doc
0
 
LVL 2

Expert Comment

by:UnHeardOf
ID: 40608592
The source address is always 0.0.0.0 until the client acks an offer from the dhcp server.

Have you tried removing option 66?

What changes did you make on the network side when this seemed to stop working? Just enabling port fast?
0
 

Author Comment

by:DougInOttawa
ID: 40614637
removed option 66, no effect.

The client, the WDS server and the DHCP server are all on the same switch.

Spanning-tree is only enabled on the specific port that we are using for the PXE client.

interface GigabitEthernet0/46
 spanning-tree portfast

are there any other configurations that should be either enabled or disabled that we normally be enabled or disabled when using the basic configuration dialog on the Cisco switch?

This is really the only difference. Previously, the switch was configured using the dialog + port fast was enabled. Then the switch was configured manually and portfast was enabled for the required port.
0
 

Accepted Solution

by:
DougInOttawa earned 0 total points
ID: 40616982
The original issue of WDS not connecting to PXE was resolved by restarting the Windows Deployment Server Services on our WDS server. PXE clients now connect to WDS and get a DHCP BOOTP address.

The switch settings were all correct, as was the option 66.
0
 

Author Closing Comment

by:DougInOttawa
ID: 40625348
problem resolved.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

The article explains the protocols and technology which is involved when two computers on different TCP/IP networks communicate with each other. In the diagram, a router is used to segregate two networks. The networks are 192.168.1.0/24 and 192…
Creating an OSPF network that automatically (dynamically) reroutes network traffic over other connections to prevent network downtime.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now