PXE DHCP issues

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
DougInOttawaAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
DougInOttawaConnect With a Mentor Author Commented:
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
 
Predrag JovicNetwork EngineerCommented:
Is on the same server DHCP and WDS?
Maybe this is the solution.
0
 
DougInOttawaAuthor Commented:
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
[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

 
tmoore1962Commented:
Double check your switch configuration for VLAN and Default gateway make sure those didn't change when you renamed the switch
0
 
Predrag JovicNetwork EngineerCommented:
Maybe some ACL is not properly configured?
0
 
DougInOttawaAuthor Commented:
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
 
vivigattCommented:
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
 
DougInOttawaAuthor Commented:
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
 
UnHeardOfCommented:
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
 
DougInOttawaAuthor Commented:
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
 
UnHeardOfCommented:
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
 
UnHeardOfCommented:
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
 
UnHeardOfCommented:
0
 
DougInOttawaAuthor Commented:
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
 
UnHeardOfCommented:
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
 
DougInOttawaAuthor Commented:
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
 
DougInOttawaAuthor Commented:
problem resolved.
0
All Courses

From novice to tech pro — start learning today.