The first thing that should be noted here is that most of the same troubleshooting you would use in DS 6.x for this error is still valid. Remember that PXE is a standard, not a product, and that all the same pieces still are used together like they would for any product.
From there though, a few things are different, and it's worth noting if for no other reason that to have a central troubleshooting spot for DS 7.x. Hopefully this KB will help.
1) TFTP failures. Symantec has their own TFTP service called _Symantec_Netboot_MTFTP. For the most part, this is a highly reliable service. However, in some circumstances, we've seen performance issues with it. Under those circumstances (which generally do not give this error), it may be useful to try a 3rd party open-source version of the same product. Again, remember this generally doesn't result in an E32 error, but just in case, you can find information about this in Article HOWTO26127
2) Preboot build failures. During the first step of the preboot process, we look for a boot.0 file. If this file is actually missing, or corrupt, you may get this error. More info is needed here.
3) DHCP configuration problems. Though we support the use of "forced mode" DHCP configurations, it is never-the-less the responsibility of the company to be sure DHCP is configured correctly. In short, Forced Mode is where we tell the DHCP server to "pretend" it's a PXE server for the initial packet request/search for a PXE server. If DHCP is not configured correctly and you're trying to use it for this, you could easily run into this problem. For instance, if you have DHCP configured with the wrong PXE server information, then the client would never be able to reach the actual PXE server to get the boot.0 file or the TFTP service.
4) Router Issues. This isn't a common reason for this particular error, but it's still possible and worth noting. The most common way to configure access to PXE servers is to use IP Helpers. These are simple commands given to the routers to tell them where to forward broadcast packets to. Every environment with a DHCP server has IP Helpers on their routers, because a DHCP request is a broadcast request and blocked by routers by default. The IP Helper forwards those packets to the DHCP server for response. Likewise, the SAME request needs to be configured to forward to a PXE server. Again, this isn't a common cause of THIS error.
5) Communication or name resolution problems. If the network is having issues resolving names, then you might run into this problem. Likewise, if you're seeing high levels of packet loss, or data corruption on the wire you might see this. Generally, we expect to have a 7 packet "communication" from start to finish of this process. E32 occurs right before packets 6 and 7 and right after packets 1-5 have completed. If any of this is corrupt, missing, or simply can't find it's destination, you might see an E32.
6) Conflicting Hardware / Software. Though not common, we've seen where hardware or software on either the PXE server or on the client can cause issues. For instance, if another piece of hardware is listening on port 67 on the server, or software, or perhaps another piece of hardware on the client is also listening for the same IP addresses. Any of these will disrupt the process. One client had an integrated management card which was using the NIC and had the same IP assigned which caused issues (disabling the management card resolved the problem).
7) Configuration Issues. One potential problem is the speed at which we transfer data. By default, we're using larger packets, but that may not work on every network. Some customers may have to shrink the packet-size to get around it, found in the NS Console under Settings | All Settings, then Settings\Deployment and Migration\Symantec Boot Services (PXE)\PXE Server Configuration. Modify the MTU size here downward if necessary.
Imported Document ID: TECH127675
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe