WIXLIB

Ports and Protocols used by Deployment Solution 6.5Page 8 of 24be used by the client. It also contains the MAC address of the client machine that the new IPaddress has been reserved for. The DHCP server will only send this out once for eachdiscovery request that it receives and then wait to hear back from the client. The full DHCPprotocol packet exchange of Discovery, Reply, Request, ACK is exchanged between thePXE client and the DHCP server (see steps 4 & 5 below). It is mentioned here because thesequence may vary from machine to machine and network to network, thus it is important tounderstand the purpose, not merely a specific observed sequence of the packets.[19]Click to view. [20]3. The PXE server will hear the client DHCP discovery request, and it will send out from its IPaddress on port 67 a UDP broadcast packet to 255.255.255.255 port 68. This packet is verysimilar to the DHCP response packet, except that it contains option 60 with the string"PXEClient", and it has option 43 with the MTFTP server IP address as well as 2 ports to useto access the MTFTP server (the port to send from and the port to receive on). Option 43 alsocontains the PXE boot menu and boot prompt information.[21]Click to view. [22]4. The client sends out another broadcast packet from 0.0.0.0 port 68 over UDP to address255.255.255.255 port 67. This packet is a DHCP request instead of the earlier DHCPdiscovery packet. Basically this is a confirmation packet telling the DHCP server that it hasreceived the offered IP address, and that it is going to be using that IP address.[23]Click to view. [24]5. The DHCP server broadcasts another packet from port 67 to port 68 containing the MACaddress of the client machine as well as the confirmed new IP address. This basically is anacknowledgement to the client machine letting it know that it has successfully reserved the IPhttp://juice.altiris.com/node/249/print5/15/2006

Ports and Protocols used by Deployment Solution 6.5Page 9 of 24address given for that client machine. The packet also can contain DNS server IP addresses,domain name, router, and subnet mask.[25]Click to view. [26]Second architecture type: DHCP and PXE reside on the same physical machine (This model will bethe case if customer is using the new functionality in 6.5 SP1 where the DHCP server isdistributing the prezero.0 and has Option 60 set to "PXEClient")[27]1. The client machine sends out from address 0.0.0.0 port 68 over UDP to address255.255.255.255 port 67. This is a broadcast packet that is attempting to discover a DHCPserver. The packet contains the client MAC address, various configurations of what formatand what items the client is expecting to receive as part of the DHCP request. The packet alsocontains in the configuration the option 60 with the string"PXEClient:Arch:00000:UNDI:002001" for a PXE boot as well.If no response is receivedright away, the client machine sends this same packet out again (sometimes this packet issent 2-3 times) (see modifications above).[28]Click to view. [29]2. The DHCP server sends out a packet from its IP address and port 67 over UDP to a broadcastaddress of 255.255.255.255 and port 68. The packet contains an available IP address that canbe used by the client. It also contains the MAC address of the client machine that the new IPhttp://juice.altiris.com/node/249/print5/15/2006

Ports and Protocols used by Deployment Solution 6.5Page 10 of 24address has been reserved for. This packet also contains option 60 with the string"PXEClient" to let the client know that this response is the PXE response as well as theDHCP response. The DHCP server will only send this out once for each discovery requestthat it receives and then wait to hear back from the client.[30]Click to view. [31]3. The client sends out another broadcast packet from 0.0.0.0 port 68 over UDP to address255.255.255.255 port 67. This packet is a DHCP request instead of the earlier DHCPdiscovery packet. Basically this is a confirmation packet telling the DHCP server that it hasreceived the offered IP address, and that it is going to be using that IP address. This packetalso contains the same option 60 as packet 1, but this option is ignored by the DHCP serverat this time.[32]Click to view. [33]4. The DHCP server broadcasts another packet from port 67 to port 68 containing the MACaddress of the client machine as well as the confirmed new IP address. This basically is anacknowledgement to the client machine letting it know that it has successfully reserved the IPaddress given for that client machine. The packet also can contain DNS server IP addresses,domain name, router, and subnet mask.[34]Click to view. [35]5. The client machine sends out a unicast packet from its new IP address over port 68 with UDPto the address of the PXE/DHCP server on port 4011. The purpose of this packet is to requestfrom the PXE server the PXE boot menu, along with all of its corresponding information.This packet is nearly identical to the packet sent in step 3, except that this time the PXEserver will see the packet and recognize that option 60 is in this packet (as this option 6

Ports and Protocols used by Deployment Solution 6.5Page 11 of 24ignored by DHCP in step 3).[36]Click to view. [37]6. The PXE server will send a unicast UDP packet to the client machine from its IP address onport 4011 to the IP address of the client machine on port 68. This packet is very similar to theDHCP acknowledgement packet in step 4, except that it is unicast and contains option 43with the MTFTP server IP address as well as 2 ports to use to access the MTFTP server (theport to send from and the port to receive on). Option 43 also contains the PXE boot menu andboot prompt information. (In SP1 if customer uses DHCP to forward clients to the correctPXE server using prezero.0 Option 67 will contain the filename and path of the prezero.0file. Option 43 will contain static information on where to connect to the real PXE server.[38]Click to view. [39]At this point the client machine will do one of a few options. The client might be running the initialdeployment boot option, the user might press [F8] and view the full PXE boot menu, there might bea job scheduled for that client, and it automatically chooses a boot option, or there might not beanything scheduled for the client machine and it automatically chooses local boot. Each of theseoptions will be detailed below.Additional Information about DHCP options 60, 54 and 43Much of the useful information that is passed between the PXE Server and client is put into theseoptions. The above information only briefly explains these options and does not go into much detailof the format of these options.Option 60 is referred to in DHCP as "Vendor-Specific Information". It is basically a string saying"PXEClient" in the packet that is sent from both a client machine that is booting off of its NIC card,and it is also in the PXE server's response. The string in that option might have more charactersthan just "PXEClient", but it must have at least that string in it. If the PXE server and DHCP are onthe same machine, this option will be set in the initial DHCP response. If those components are onseparate machines the DHCP server response will not have that option, but the PXE server will.The option in the clients DHCP request lets the PXE server know that the client wants to PXE bootas well as get a DHCP server. The option in the PXE servers response lets the client know who thePXE server is, and who to request more information from to continue the PXE 006

Ports and Protocols used by Deployment Solution 6.5Page 12 of 24Option 54 is labeled as "Server Identifier". This is an IP address that will be used by the client torequest the start of the boot file download from the MTFTP server. Usually this address will be thesame as the PXE server, but it can be different if the PXE server and MTFTP server are on differentphysical machines. The IP address for the MTFTP server in option 43 does not contain the direct IPaddress, but rather the multicast IP address. This option is needed so that the client can directlyaddress the MTFTP server without sending a multicast/broadcast packet.Option 43 is only sent from the PXE server to the client. This option contains many values and isbroken into various sub options. This option contains all of the data that the client needs to requestany PXE boot option. The sub-options (and data contained) in option 43 are as follows: MTFTPserver IP address along with ports to send from and to send to, the MTFTP timeout and delaytimes, the PXE boot control and boot servers, the PXE boot menu and PXE prompt. The PXE bootmenu will have the default menu choice item at the top (this menu order is dynamically made foreach client based on what jobs are assigned to the client). The boot menu also has in the 3rd byte ofthe field the menu timeout. If that byte in the menu is 00, the top option will automatically bechosen immediately. If that byte is 03 then it will wait 3 seconds before choosing the top menu item(such is the default case of local boot when no jobs are assigned), and if that byte is FF, the menuwill wait indefinitely (this is the default behavior of initial deployment).Step 2: PXE Boot menu option selectionLocal Boot:If a user is at the client machine while it is booting up and they manually press F8 and select localboot, or if they press escape during the above PXE boot process, no further packets are sent fromthe client in regards to PXE, and the client machine continues the BIOS boot order (most likely theproduction hard drive next).If no user is at the client machine and the boot menu times out (determined by the boot menu inoption 43) then the client machine will use the boot item that is first on the boot menu. If thatoption was local boot, no further communication will be made between the client and the server.The BIOS will just continue to the next boot option after the NIC card (usually the production rint5/15/2006

Ports and Protocols used by Deployment Solution 6.5Page 13 of 24Click to view. [41]Automation OS boot part 1(Downloading the .0 file):1. Regardless of the PXE menu choice selected, and how it is selected (whether it wasautomatically selected because it was at the top of the list, or a user at the machine manuallyselected one of the options). Once the client knows which menu choice it is going to chooseis sends a UDP datagram to the PXE server for more information about that specific menuchoice so that it can start to download it. This is a UDP packet sent unicast from port 4011 tothe PXE server's port 4011. This packet does not contain any DHCP options (such as 60)because the DHCP process is over at this point. The packet is simply a UDP datagram of 548bytes that contains the request for boot control from the PXE server in an Altiris proprietaryformat.[42]Click to view. [43]2. In response the PXE server sends down a unicast UDP packet from port 67 to the IP of theclient machine on port 4011. This packet is almost the same as the previous DHCPacknowledgement except that instead of having no boot file name, the boot file name is in thepacket as the file on the MTFTP server to download (the .0 file name). This response also hasoptions 60 and 43, but the data in them is already on the client. The only reason for thoseother options is so that the client knows that this DHCP response is a direct result of itsrequest for the file name of the .0 file for the selected boot menu item.[44]Click to view. [45]3. The client machine now knows exactly what file to ask for from the MTFTP server. It alsoknows the direct IP address of the MTFTP server (this is from option 54 of the PXE/DHCPresponse). The client machine sends a unicast datagram UDP packet from port 1758 to thedirect IP address of the MTFTP server IP address on port 1759 (Ports 1758 & 1759 are thedefault ports used for MTFTP requests and responses, but these ports can be configured inthe PXE configuration tool. For the rest of this tutorial these defaults will be used). The datain this packet is in an Altiris proprietary format, but mainly contains the .0 boot file name,and a request for 15/2006

Ports and Protocols used by Deployment Solution 6.5Page 14 of 24[46]Click to view. [47]4. The client machine sends another packet right away to the MTFTP multicast address. This isan IGMP membership report packet. There are no source or destination ports in this packet,and in fact it is not received by any other computers on the network. The purpose of thispacket is to let the switches (and other level 2 devices) in this network know that this clientmachine is part of the multicast group for the multicast address that it has sent out. Whenevermulticast packets of the reported address are sent from this point on, they will be sent to thisclient machine.[48]Click to view. [49]5. The MTFTP server will next start sending the first .0 boot file. The first packet will be senttwice. Once to the direct IP address of the client machine, and the other to the multicastaddress established by the MTFTP server. These packets will be UDP datagrams going fromport 1759 to the client port of 1758.[50]Click to view. [51]6. The client machine after receiving the packet will respond with a small unicast UDPdatagram packet from its IP address on port 1758 to the direct IP address of the MTFTPserver on port 1759. This packet is just a confirmation that it received the last packet from theMTFTP server. It also lets the MTFTP server know which of the first 2 packets it received(either the multicast one of the directed 006

Ports and Protocols used by Deployment Solution 6.5Page 15 of 24[52]Click to view. [53]7. The MTFTP server will send the next UDP datagram packet of the .0 boot file. This packetwill be either a multicast packet or a unicast packet depending on the response it receivedfrom the client in its previous communication. Once this format is defined it will continue tosend the UDP datagram packets in this format until the entire .0 file is sent down.[54]Click to view. [55]Steps 6 and 7 are repeated alternatively until the MTFTP server has sent down its last packetcontaining the end of the .0 file, and the client has sent its final acknowledgement.Contents and purpose of the .0 fileAll automation OS environments have a .0 file. This file was called in DS 6.1 managed.0 ornewcomp.0 (for Managed PC and Initial Deployment respectively). In 6.5 these files will be namedafter what order they appear by default in the PXE boot menu. The first PXE boot file will have afile named MenuOption128.0 and the second one will have a boot file named MenuOption129.0 etc.Once this file has been downloaded completely from the MTFTP server, the client will load the fileinto memory and start to execute the file's code. This file is a bootstrap program that tells the clientmachines how much memory to allocate for the rest of the pre-boot operating system, and whatother files will be included in the pre-boot operating system. The bootstrap program also starts therequests for the other boot files, loads those into memory, and then transfers control over to thoseother programs (generally those are the actual pre-boot OS). Usually this file is somewherebetween 15-25 KB (depending on what the rest of the boot OS is) in size, but never larger than32KB.Loading the rest of the OSAt this point the .0 file has control of the rest of the PXE boot process. Each of the environmentshas a different .0 file and thus a different method for continuing the rest of the pre-boot OS. Forexample DOS re-establishes a new multicast session with a new multicast IP and then startsdownloading a .1 file. Linux stops using multicast and goes to TFTP and starts downloading 6

Ports and Protocols used by Deployment Solution 6.5Page 16 of 24pxelinux.cfg file. WinPE also stops using multicast and uses TFTP to start downloading theNTLDR file. There could also be a custom OS that behaved in a completely different manner.Normally after the boot loader program (the .0 file) has finished setting up memory and loaded therest (or at least some of the other) of the OS files into memory it transfers control to some otherprogram to actually run the pre-boot OS.The entire PXE process is employed simply to create a virtual boot floppy in the client that loadsthe Altiris BootWorks program. The BootWorks program functions as a DOS client for AltirisDeployment Server. This program checks for and executes any pending work assigned to the clientcomputer by the Deployment Server management console.Additional ConsiderationsPXE won't work with a DHCP relay or DHCP gateway (like Cisco's DHCP relay). Thereason for this is that the RELAY makes the request for the IP address which means itprovides the wrong MAC address. The computers will PXE boot but will not be able toautomatically detect if there is work for that computer; instead it will default to the InitialDeployment event boot.With Cisco switches, sometimes there can be problems with PXE timing out while goingthrough its spanning tree states. If you have a Cisco switch and you have spanning treeconfigured, the computer requests might time out because the switch will not let any trafficgo through the port until the spanning tree negotiation is finished (Cisco Spanning Tree timeout is 45-55 Seconds). The work around for this is to use the PortFast command on the Ciscoswitches which allows you to enable traffic to go through the port before negotiation isfinished.It may be prudent to configure the routers with statements to forward DHCP discovers toboth the DHCP and the Altiris PXE servers.ImagingRapiDeploy: Imaging engineRapiDeploy is the disk imaging product that DS uses to perform disk imaging tasks. RapiDeploycan multicast disk images across a network to decrease the amount of network bandwidth used. Theports and IP multicast address ranges used by RapiDeploy can be configured from within theDeployment Server Console. Go to TOOLS Options and select the RapiDeploy 06

Ports and Protocols used by Deployment Solution 6.5Page 17 of 24[56]Click to view. [57]The default IP range is 224.2.0.2 - 224.2.0.20 and can be changed by the end user.The default PortRange is UDP 401 - 401.Each new disk imaging job will use a new multicast IP address in the default range to makemulticasting more efficient. For example, if you start two separate imaging jobs on a single subnet,the imaging tasks will be able to see each other's packets. If a different multicast IP address is usedfor each job, the the NIC can filter out the packets that are coming from the other imaging job andwill therefore not clog up it's IP stack with useless data. If you want to only use one multicast IPaddress, you can set the start and end IP addresses to be the same address and then put in a range ofports, 401 - 420, for example. This will keep the same IP address for all jobs but will cycle throughthe port numbers used for each job. This will also help keep packets from imaging jobssimultaneously running

and protocols used by Altiris Deployment Solution version 6.5. Altiris Deployment Server 6.5 (build 233) Routers and Switches Routers should be enabled for multicast for these IP ranges: Deployment Agent for Windows (AClient) uses 225.1.2.3. RapiDeploy (the disk imaging engine) uses 224.2.0.2 to 224.2.0.20 by default, but this is configurable.