- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Aruba & ProVision-based
- >
- Re: ProCurve 2620-24, no PXE boot after sw15.14.00...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-03-2016 06:32 AM - edited 06-03-2016 06:40 AM
06-03-2016 06:32 AM - edited 06-03-2016 06:40 AM
ProCurve 2620-24, no PXE boot after sw15.14.0009
Hi Community
Firstly, I hope this is the right forum location, if not please point to a more appropriate, and I'll move to that :)
We have a bunch of older J9623A switches, that we would like to update to the latest software version.
However, as soon as we updated to 16.01.0006 we were unable to PXE boot from our SCCM server across subnets.
By trial and error we have determined that the problem start as soon as we get past 15.14.0009.
Our two DHCP servers (one active, one standby), and the SCCM server are all on different boxes but same subnet.
The DHCP options 66 and 67 have both been set on the relevant scopes.
The clients are mostly on different subnets and VLANs. A few are on the same subnet as the servers.
There are no firewalls/ACLs between the clients or the servers.
When trying to PXE boot a client we get the following messages:
_________________________________________________________________
Downloaded WDSNBP from SCCM_IP_ADDRESS
WDSNBP started using DHCP Referral.
Contacting Server: SCCM_IP (Gateway: SUBNET_GW_IP)..
No response from Windows Deployment Services server.
Launching pxeboot.com...
Press F12 for network service boot
[We hit F12, and get a Windows 8 BSOD:
Recovery
Your PC/Device needs to be rapaired.
The Boot Configuration Data for your PC is missing or contains errors.
File:\boot\bcd
Error Code: 0xc000000f]
_________________________________________________________________
We have tried disabling STP and DHCP snooping as well as adding the SCCM server as ip helper-address (mostly because other forum posts suggested this, though I can't really see how that would make any difference when the SCCM server doesn't respond to DHCP requests?),
but so far we can only get it working with sw version 15.14.0009 and below, with STP and DHCP snooping enabled, and just the two DHCP servers as ip helpers.
If the SCCM server and client are in the same VLAN/subnet there are no problems PXE booting regardless of switch software version.
Nothing in the release notes for 15.14.0010 points us to a reason for this. But maybe someone with some more Procurve expertise can see something we cant?
Best regards
Robert Eriksen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-05-2016 07:01 PM
06-05-2016 07:01 PM
Re: ProCurve 2620-24, no PXE boot after sw15.14.0009
I have a dim memory of encountering this issue about 6 years ago - I may be wrong, but I think enabling multicast routing was how I fixed it.