Patent Application
20050180326
The present invention relates generally to communications with terminals over a data transmission network. More particularly, the present invention relates to a method and system for finding and using one peer computing device to remotely and/or automatically perform on an other computing device an operation (such as wakening and/or remotely booting), even if the other computing device is located on a different subnet and communicates through an intermediate device which restricts or prevents passage of a command for the operation from the initiating device.
Various forms of data transmission networks are well known in the prior art. Some such data transmission networks involve datalink protocols such as Ethernet or asynchronous transfer mode (ATM) communication. The preferred embodiment of the present invention will be described in this document within the context of an Ethernet datalink protocol network, although it is not limited to such and would have similar applicability to ATM, token ring or other forms of network and subnet communication.
A set of services known collectively as the Preboot Execution Environment (PXE) provide the capabilities to remotely “boot” a software image onto a computer system over a data transmission network, prior to loading an operating system that exists locally on the machine. These PXE services can be used for a variety of functions including: recovering a software system to a previous state, installing an operating system for first time use, resetting a system to a different operating system image or migrating a system to a newer operating system image. PXE uses a Dynamic Host Configuration Protocol (sometimes referred to as DHCP), BOOTP and the Trivial File Transfer Protocol (TFTP) in order to facilitate the boot process across a network Wake-on-LAN technology enhances the PXE remote boot service process by providing the ability to turn on (or awaken) a target computer machine which had been turned off for remote boot operations without human interaction on the target computer machine. These PXE and Wake-on-LAN technologies need to fit into corporate network infrastructures which contain routers, firewalls and other DHCP servers. However, there are significant issues that need to be overcome in order to successfully deploy remote boot services such as PXE in a typical corporate network environment. In order to understand these issues and the complexity of the problem, the following brief description of a few different data transmission network topologies is given to provide an understanding of the present invention in the context of a variety of existing data transmission networks, with and without PXE services.
The simplest data transmission network involves a flat single IP subnet network, which includes no routers or firewalls that interconnect portions of the internal network Routers and firewalls are only used to connect the internal network to the outside world. This is a simple configuration for a data transmission network and one which easily accommodates remote boot services such as the PXE, however this single flat subnet network is not a typical configuration for medium to large corporate networks.
A typical flat single IP subnet network might exist without PXE services. Its Ethernet segment includes hubs, bridges, switches and other Layer 2 devices, but still appears to the network layer as a single IP subnet. There are no routers on the internal network where the client machines and the DHCP server are connected. This type of a flat single IP subnet network might include a DHCP server which provides IP addresses to clients by directly responding to each client DHCP request for an IP address.
A flat single IP subnet network as described above may be enhanced to provide the subnet with PXE services. Inclusion of the PXE services may include some or all of the functions which have been previously mentioned, including Wake-on-LAN, DHCP, BOOTP and TFTP technology which have been added to the single flat IP subnet network to implement PXE services. Wake-on-LAN is used if it is desired to turn on or awaken a target computer, such as a personal computer or PC which had been turned off. Wake-on-LAN wakes up the target PC and starts the remote boot process. A PXE boot server contains specialized DHCP services in order to respond to remote boot requests. These boot requests are embedded in the DHCP protocol. Each DHCP server is responsible for a different role in this environment. An original DHCP server continues to provide IP addresses to each client whether they are network booting or not The PXE DHCP server is responsible for providing the BOOTP server IP address to each client that is remote booting.
A higher level of complexity for a data transmission network involves a routed IP network, where one or more routers and/or firewalls interconnect portions of the internal data transmission network This type of network configuration is very common in medium to large corporations and there are significant issues to work around in order to supply remote boot services because the routers and firewalls are designed and operated to prevent the use of PXE services and other remotely initiated services from passing through. A typical routed IP data transmission network without PXE services includes an internal router between different Ethernet segments. The router is configured to relay DHCP requests to the DHCP server that is outside of the client IP subnet. DHCP requests are broadcasted on the local network segment by each client. Without a router relay function, these requests would not get off the network segment from which the request originated.
Another data transmission network configuration is a routed IP network with PXE services. This network combines the typical corporate network with remote boot services provided by one or more PXE servers. The first problem encountered with this type of data transmission network is getting any Wake-on-LAN messages to the appropriate clients located across the internal router/firewall. In order to do so, UDP or TCP ports have to be opened up on the internal router/firewall, which is a security risk. Therefore, instead of using Wake-on-LAN, typically the PC is manually woken up. The second problem is getting the DHCP requests to the PXE DHCP server. The internal router would have to be reconfigured for an application that uses PXE Boot Services to send DHCP requests to the original DHCP server and the PXE Boot Server. If the router does not support relaying to multiple DHCP servers, then the PXE Boot services will not work. Scaling this environment to one that has multiple applications that use remote boot services across multiple routers gets even more complicated and difficult to set up. Each router would have to be reconfigured for each application with remote boot services.
It might be suggested that each network subnet be provided with its own services at all times. While this would avoid the need to pass service commands through the routers/firewalls which connect the subnets, such a system could involve much unnecessary communications to establish and maintain such services. For example, the services must be established at set-up of the network and each time devices leave the network, lest the device that left the network was relied upon to provide the services such as wake-on-LAN. Since many networks have a continual change in the configuration of the network because devices are constantly leaving and joining the network keeping the services available on each subnet could be burdensome and require significant resources, which may or may not be used. It might also be suggested that each network subnet be provided with its own services at all times through dedicated, static equipment. This is also burdensome since each subnet would require significant additional resources to provide the required functionality that can otherwise be dynamically provided by peer resources that are already on the network.
Thus, the foregoing illustrates that the systems of the prior art have significant disadvantages and limitations.
The disclosed technique overcomes the above limitations by allowing devices to be provided with remote services (awakened and/or remotely booted through a PXE server with Wake-on-LAN capabilities) in networking environments with multiple IP network segments or subnets. The technique of the present invention solves the issue of using Wake-on-LAN technology through routers and firewalls by leveraging peer devices to perform these services. It also uses peer devices to address the issue of providing DHCP services in a PXE server through routers and firewalls. This technique solves DHCP issues without requiring routers to be reconfigured or replaced to support multiple DHCP servers. Finally, it solves the problem of using multiple PXE servers without requiring the PXE servers to be aware of one another.
In today's typical networked environments, deploying PXE servers with Wake-on-LAN to remote boot computers is extremely difficult to do. Therefore, most PXE services are relegated to a controlled environment such as a lab. By solving the issues related to using PXE servers and Wake-on-LAN in a routed network, corporations can use PXE services across their entire network and leverage applications that take advantage of PXE.
The present invention also avoids the need to provide all subnets with a full complement of services and to update the services when a device is removed from the network.
The present invention also overcomes any need to identify what services may be required on what subnet and to provide those services on the identified subnet.
Other objects and advantages are inherent in the present invention and will be apparent to those of ordinary skill in the art. Thus, the limitations and disadvantages of the prior art systems are overcome by the present invention.
Other objects and advantages of the present invention will be apparent to those of ordinary skill in the art from the detailed description that follows along with the accompanying drawings, wherein:
An arrow 130 illustrates a Wake-on-LAN message from the PXE boot server 118 which is directed, in this example, to the selected computer terminal 112. When the selected computer terminal 112 receives the Wake-on-LAN message, it broadcasts a request 132 for a client IP address and a BOOTP server address. The PXE boot server 118 replies as illustrated by the arrow 134 with the BOOTP server address which is required for the computer terminal 112 to continue the PXE boot process. The DHCP server 120 replies as illustrated by the arrow 136 with the client IP address so that the computer terminal 112 will have an IP address which is recognized and registered with the DHCP Server 120 for communication with other terminals and with the rest of the network.
In this case, the network includes a second Ethernet subnet or segment 200 which is coupled to the first Ethernet segment 100 through an internal router/firewall 210 and has attached to the second Ethernet segment the PXE boot server 118 and the DHCP server 120. In addition, the second Ethernet subnet 200 also includes a connection to the Internet 124 through an external router or firewall 122.
As illustrated in this Figure, in some cases the PXE boot server 118 would try to send a message to a terminal 112 as illustrated by the dotted arrow 130 in
If terminal 112 is to be awakened, it must be awakened manually in this arrangement, then generate a message 132 to request a client IP address and a BOOTP server address, which is then relayed as message 142 to the PXE server and as message 144 to the DHCP server. The PXE boot server 118 responds with message 134 with the BOOTP server address response and the DHCP server 120 responds with message 136 with the Client IP address response which are relayed to the terminal 112 through the internal router/firewall 210 as messages 146 and 148, respectively. The messages other than the message indicated by the dotted arrow 130 are considered safe messages which are not affected by the security processes of the internal router/firewall 210, but the message 130 (to awaken the device) is considered sensitive and would not pass through a router/firewall. Message 130 is considered sensitive since it is an unsolicited request initiated from the outer Ethernet segment 200 towards the internal Ethernet segment 100. By default, firewalls protect against unsolicited requests and only allow responses to requests initiated from an internal Ethernet segment to be passed back to an internal Ethernet segment. Of course, one could turn off the security by opening the ports of the firewall, but that would destroy one security feature of the firewall/router. Though message 132 is considered a safe message, it still requires special configuration on the internal router/firewall 210 in order to properly relay DHCP requests such as message 142. If additional router/firewall devices are added to the network, each of these devices requires the additional manual configuration for each PXE server on the network.
In the embodiment shown in
The remote boot services are controlled through an external management system 300 coupled to the Internet. The services provided by the PXE Boot Server are dynamically deployed onto a peer client on the local subnet. The peer client is told which device to provide PXE Boot services to and does not respond to other clients. The peer client issues the Wake-on-LAN request on the local subnet which solves the problem of using Wake-on-LAN through routers. The peer client also responds to the booting client DHCP request to supply the BOOTP server address. This eliminates the need to reconfigure any routers to forward DHCP requests to additional servers. The rest of the PXE services such as BOOTP and TFTP are also provided by the peer device in order to download the boot image code to the destination PC. Once the PXE boot operation is complete, the peer device is told to stop responding to PXE requests.
In this embodiment, the process is started when the Management System 300 decides to remote boot a PC and instructs the PXE Boot Server 118 to do so through message 152.
In
The remote boot process starts on the target PC (terminal 112) when it is turned on. The PC automatically turns on when it receives a Wake-on-LAN message which is commonly known in the industry as a “Magic Packet”. A Magic Packet is a well-formed data packet, such as an Ethernet packet, that contains within it a PC's MAC address repeated 16 times preceded by 6 bytes of FFh. When a PC that supports Wake-on-LAN sees its Magic Packet, it will wake up and start the remote boot process. If a PC's MAC address is 001122334455, then the following sequence inside an Ethernet frame will wake it up. Note that this sequence of data can be located anywhere in the data packet.
If the PXE server (e.g. terminal 118) sits outside a firewall (210) and tries to wake up a client (e.g., terminal 112) inside a firewall (as shown in
The disclosed technique uses a Peer PC (e.g., the terminal 114) to issue the Magic Packet. Message 156 from terminal 114 in
Once the destination PC (terminal 112) wakes up, it goes through its normal remote boot process. This process is described in depth in “Preboot Execution Environment (PXE) Specification, Version 2.1, Intel Corp., September 1999.” PXE uses option fields in DHCP messages to provide the PXE extensions to the DHCP protocol. The first message issued by the woken PC, represented by message 158 from terminal 112, is a DHCP Discover request with an option that contains the “PXEClient” extension. This message serves two purposes. The first purpose of this request is to get its IP address from the normal DHCP server. The second purpose of this request is to get the IP address of the BOOTP server that the client needs to continue the remote boot process with. The DHCP Discover request sent by the client does not have the proper source IP address in it since this message is used by the client to find out its own IP address. The message also does not have the proper destination IP address in it since the client does not know the IP address of any of the DHCP servers. Therefore, it is up to the IP router to property relay this message to the machines providing the DHCP service. In a PXE Boot environment, there are typically multiple DHCP servers and therefore the IP router must be configured to relay the DHCP requests to both the normal DHCP server and all of the PXE Boot servers. This means that when an application that leverages PXE services is deployed in an IP network, the routers that control the IP network need to be reconfigured to forward the DHCP requests to a PXE server.
The disclosed technique, as shown in
Once the destination PC, terminal 112, receives the Extended DHCP Offer from the PXE Boot server 114 and completes its handshaking with the normal DHCP server 120 to acquire an IP address (messages 164 and 166), it continues the boot process by issuing another DHCP Discover request to the Peer PXE Boot server 114 to determine which boot file to load. The Peer PXE Boot server responds with the appropriate boot file name in a second Extended DHCP Offer. The destination PC, terminal 112, then uses the TFTP protocol to download the boot file directly from the Peer PXE Boot server 114.
Once the boot process is complete, the Master PXE Boot server 118 turns off the PXE boot services on the Peer device (the terminal 114). When subsequent remote boot operations are required on the same IP subnet, the Master PXE Boot 118 server goes through the process again of selecting a Peer device to perform these operations. The Master PXE Boot server 118 will typically select a Peer device or terminal that already has the PXE services installed over a Peer without the PXE services installed. However, the Master PXE Boot server 118 may select a different peer device (e.g., the terminal 116 in
The invention also allows multiple applications that use remote boot services to work in the same corporate network without requiring these applications (or their associated remote boot servers) to communicate or be aware of one another. With the invention, each application can independently deploy PXE boot services to peers as needed. They operate independently, only respond to clients using their service and do not require each router to be reconfigured to send DHCP requests to all of the PXE boot servers.
If the selected terminal for the services is determined not directly available (for example, not on the same subnet or with an intermediate firewall or router) at the block 410, then at block 430 a peer terminal or personal computer PC2 is selected which is on the same subnet as the particular terminal PC1 (or is otherwise accessible to the particular terminal PC1 without an intervening firewall or router). Then, block 440 determines whether the selected service (e.g., PXE Boot service) is available from that peer terminal PC2. If so, then the service is used at block 450. If not, then at block 460 code to implement the service is sent using a file transfer facility (one which will go through the firewall or router such as, but not limited to, a client initiated FTP session). That code to implement the PXE Boot facility then is installed at block 470 on the peer terminal PC2 and then the service is started at block 450 to provide the service to the particular terminal PC1, which services are then implemented at block 480.
Of course, many modifications to the preferred embodiment will be apparent to those who work in the relevant art. For example, the services being provided have been discussed using PXE services such as Wake-on-LAN, DHCP and BOOTP, but, in fact, the present invention is not so limited and this invention can be used to advantage with any type of services which are filtered, prevented, altered or hindered across a firewall or router. Further, the present invention has been described in the environment of Ethernet network protocols where it is also useful in other types of networks such as asynchronous transfer mode (ATM) or other communications protocols such as IPX or Appletalk. Further, it may be advantageous to use certain components of the present invention without the corresponding use of other components which have been disclosed as a part of the preferred embodiment. As an example, there may be applications that only need to provide a Wake-on-LAN service through a peer machine to force a device to boot into its core operating system. The present invention is described in the context of routers and firewalls, which may be implemented in either hardware or software or in some combination thereof. Further, the description of a routed network may, itself, be as a result of using hardware or software combined with hardware. Thus, the foregoing description should be considered as merely illustrative of the principles of the present invention and not in limitation thereof, as the present invention is defined solely in the following claims.
