A method of enabling remote booting of a remote boot client in a switched network defining a plurality of virtual local area networks (vlans). The switched network may include a first trunking aware switch, a first remote boot client and a remote boot server and the method may include setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native vlan of the plurality of vlans; receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode; directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native vlan; receiving selected files from the remote boot server on the first predetermined native vlan and forwarding the received files to the first remote boot client on the first predetermined native vlan, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of vlans and to send traffic to the first trunking aware switch on the specified one of the plurality of vlans.
|
1. A computer-implemented method of enabling remote booting of a remote boot client in a switched network defining a plurality of virtual local area networks (vlans), the switched network including a first trunking aware switch, a first remote boot client and a remote boot server, the method including steps of:
setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native vlan of the plurality of vlans;
receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode;
directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native vlan of the plurality of vlans;
receiving selected files from the remote boot server on the first predetermined native vlan and forwarding the received files to the first remote boot client on the first predetermined native vlan, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and
switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of vlans and to send traffic to the first truniking aware switch on the specified one of the plurality of vlans.
15. A computer-readable medium having data stored thereon representing sequences of instructions which, when executed by a first trunking aware switch, causes said first trunking aware switch to enable remote booting of a first remote boot client in a switched network defining a plurality of native virtual local area networks (vlans) and including a first remote boot client and a remote boot server, by performing the steps of:
setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native vlan of the plurality of vlans;
receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode;
directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native vlan of the plurality of vlans;
receiving selected files from the remote boot server on the first predetermined native vlan and forwarding the received files to the first remote boot client on the first predetermined native vlan, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and
switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of vlans and to send traffic to the first trunking aware switch on the specified one of the plurality of vlans.
8. A computer system suitable for enabling remote booting of a first remote boot client in a switched network defining a plurality of native virtual local area networks (vlans), the computer system comprising:
a first remote boot client;
a remote boot server;
a first trunking aware switch, the first trunking aware switch including:
at least one processor;
a plurality of processes spawned by said at least one processor, the processes including processing logic for:
setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native vlan of the plurality of vlans;
receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode;
directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native vlan of the plurality of vlans;
receiving selected files from the remote boot server on the first predetermined vlan and forwarding the received files to the first remote boot client on the first predetermined native vlan, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and
switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of vlans and to send traffic to the first trunking aware switch on the specified one of the plurality of vlans.
3. The computer-implemented method of
4. The computer-implemented method of
5. The computer-implemented method of
6. The computer-implemented method of
7. The computer-implemented method of
10. The computer system of
11. The computer system of
12. The computer system of
13. The computer system of
14. The computer system of
17. The computer-readable medium of
18. The computer-readable medium of
19. The computer-readable medium of
20. The computer-readable medium of
21. The computer-readable medium of
|
1. Field of the Invention
The present invention relates to computer-implemented methods and systems for remotely installing an operating system on a diskless and/or stateless computer system in a switched network defining a plurality of virtual local area networks.
2. Description of the Prior Art and Related Information
A virtual Local Area Network (VLAN) is a way of segmenting a local area network into several logical networks. These logical networks may reside on the same physical network, but offer a mechanism to allow groups of users to establish their own logical network to securely share data and resources. Several VLANs can co-exist on a single switch, which is a computing device that connects network segments. Switches provide all necessary filtering, identification and transporting of the frames transmitted within and between VLANs. One method for segmenting users into VLANs is through the use of tags, a way of identifying packets through the use of VLAN identifier (VID) bits. IEEE protocol 802.1q is the currently predominant protocol for enabling several VLANs to co-exist on a single switch. The 802.1q protocol calls for a 12 bit VID header (among other fields) to be added to the standard Ethernet header, which enables the identification of a theoretical maximum of 212 or 4096 VLANs. A non 802.1q Ethernet frame may be 1518 bytes in length, whereas an 802.1q Ethernet frame may include 1522 bytes, to account for the overhead of specifying the VLAN and other housekeeping issues as specified in the IEEE 802.1q standards. Therefore, the switch may identify the VLAN to which a particular frame is to be routed based upon the tag of that frame, which tag contains the VID. Prior to routing the packet to its intended target on the identified VLAN, the switch may strip the header of its VID and other fields that may have been added by the VLAN protocol. Other methods for routing packets to particular VLANs exist, such as packet filtering, for example.
Ports on a switch may be assigned to a single VLAN in a static manner. Static VLANs are very secure and do not require the network administrator to maintain table of Media Access Control (MAC) addresses and/or filtering tables. MAC addresses are hardware address that uniquely identify node of a network. Each port on a switch may also be dynamically assigned to multiple VLANs depending upon, for example, the MAC address of the target destination of the frame being transported. Such ports are called dynamic VLANs. Ports may be configured and operated in three modes. The first mode may be an access mode (also variously called untagged or promiscuous/isolated mode), in which a port is assigned a specific native VLAN and all Ethernet traffic from devices coupled to the port will only be visible to ports configured to the same native VLAN. The second mode is a tagged mode (also variously called trunking or “dot1q”), in which frames from devices coupled to the port must include the VID to identify to the switch to which VLAN the frame is to be routed. Ports configured in trunk mode according to the 802.1q protocol are typically called “dot1q” configured ports. The third mode is a combination of the first and second modes, where the first mode's boot-up VLAN must also be specified at “dot1q” level for clients spanning across more than one dot1q enabled switch and ports can only be set in promiscuous mode.
In order for a server to access multiple VLANS, the server must include a Network Interface Card (NIC), a network cable and a port on the switch for each VLAN to which access is desired. For a server to access three VLANs, for example, the following is required: three NICs, three cables and three network ports, on for each VLAN to which the server wishes to access. Servers are typically mounted in racks, and each rack may have, for example, 18 servers. For each server within the rack to access three VLANs, therefore, a total of 54 cables are necessary, exclusive of the power cables, switch cables to distribution switches, and remote management interface(s). If High-Availability (bonding) is to be provided for each VLAN, a total of 108 cables may be required for each rack. It is not unusual for high capacity data centers to have many racks of servers. From the foregoing, it becomes clear that the cost of purchasing, installing, managing and maintaining such cables is not inconsequential for large scale data center operations. Moreover, such a large number of cables increases the likelihood of cable failures and may increase the downtime of the constituent servers in the individual racks.
The 802.1q defines a protocol that, among other benefits, allows for a reduction in the number of cables needed by a server to access multiple VLANs, since a single cable may carry Ethernet traffic destined to any one of a plurality of VLANs. Other protocols exist for accessing and managing several VLANs, such as Cisco Systems' proprietary ISL protocol, for example. Implementation of the 802.1q protocol and like protocols simplifies the network architecture, decreases the costs associated with enabling servers to access multiple VLANs and increases the reliability of the network.
It is often desired to return individual servers to a reference state. To insure that the servers may be returned to such a reference state, diskless and stateless servers may be used to good advantage. Such diskless/stateless servers may store and operate their operating system on and from a Random Access Memory (RAM) disk. Also useful is the ability to load and boot such a diskless/stateless server using a selected one of several operating systems, and to do so remotely. Such a remotely booted diskless/stateless server may be loaded with a selected operating system and returned to a reference state (in effect, “wiped clean”), affording the network administrator with a great degree of flexibility in how such servers are deployed. To enable such remote loading and booting, a client/server interface called Preboot Execution Environment (PXE—pronounced “Pixie”) may be implemented, among other proprietary and/or open protocols. PXE allows network computers to load and boot their operating system remotely by a system administrator.
Network File System (NFS) is a protocol that allows a computer to access files over a network as easily as if they were on its local disks. NFS is strongly associated with UNIX systems, though it can be used on other platforms. RAMFS is a RAM Filesystem in which the operating system (such as versions of Unix or Linux, for example) is loaded over the network into the server's RAM. In this manner, the server may be diskless and stateless, as noted above. Problems arise, however, when attempting to use PXE in an 802.1q environment, as PXE (and similar remote booting protocols) does not provide for the 802.1q trunking technology, which allows multiple segmented networks (VLANs) to use a single cable (or two cables when High-Availability bonding technology is used). Accordingly, when it is desired for servers to have the ability to remotely load and boot their operating system from the network, it is currently not possible to benefit from the economies afforded by the 802.1q protocols or other similar trunking protocols. This means that when remote boot operations are required in a multiple VLAN system, it is necessary to revert back to the costly and complex one cable/one NIC/one VLAN conventional architecture. Diskless/stateless systems (that is, systems that require the ability to remotely load and boot their operating system), therefore, are conventionally unable to couple to a trunking port of a switch configured according to the 802.1q or similar protocol.
From the foregoing, it may be appreciated that methods and systems are needed that would allow such diskless/stateless servers to load and boot their operating systems remotely over network configured according to a trunking protocol, such as, for example, the IEEE 802.1q protocol.
Embodiments of the present invention include a computer-implemented method of enabling remote booting of a remote boot client in a switched network defining a plurality of virtual local area networks (VLANs), the switched network including a first trunking aware switch, a first remote boot client and a remote boot server. The computer-implemented method may include steps of setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native VLAN of the plurality of VLANs; receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode; directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native VLAN of the plurality of VLANs; receiving selected files from the remote boot server on the first predetermined native VLAN and forwarding the received files to the first remote boot client on the first predetermined native VLAN, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of VLANs and to send traffic to the first trunking aware switch on the specified one of the plurality of VLANs.
The switched network may be 802.1q compliant. The switched network may further include a network file system coupled to the switch, and the method may further include a step of the first remote boot client requesting additional files from the network file system over the first port configured in the second mode. The request for remote boot in the receiving step may be carried out according to the Preboot Execution Environment (PXE) standard client-server interface. A step of the first trunking aware switch receiving traffic from the first remote boot client may also be carried out, the received traffic including frames comprising VLAN tags specifying one of the plurality of VLANs. The selected files in the receiving step may enable the first remote boot client to create a RAM disk that is configured to be mounted as a root file system from to enable programs to be run from the mounted RAM disk. The switched network may include a second remote boot client that is coupled to a second trunking aware switch, the second trunking aware switch being coupled to the first trunking aware switch via ports configured in the second mode that enable the second remote boot client to specify one of the plurality of VLANs in addition to the first predetermined native VLAN. The method may further include a step of the second remote boot client requesting remote boot on the first predetermined native VLAN and receiving selected files from the remote boot server, across both first and second trunking aware switches, on the first predetermined native VLAN via the ports configured in the second mode.
According to another embodiment thereof, the present invention is a computer system suitable for enabling remote booting of a first remote boot client in a switched network defining a plurality of native virtual local area networks (VLANs). The computer system may include a first remote boot client; a remote boot server; a first trunking aware switch, the first trunking aware switch including: at least one processor; a plurality of processes spawned by said at least one processor, the processes including processing logic for: setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native VLAN of the plurality of VLANs; receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode; directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native VLAN of the plurality of VLANs; receiving selected files from the remote boot server on the first predetermined VLAN and forwarding the received files to the first remote boot client on the first predetermined native VLAN, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of VLANs and to send traffic to the first trunking aware switch on the specified one of the plurality of VLANs.
The switched network may be 802.1q compliant, for example. The switched network may further include a network file system coupled to the switch, and the method may further include a step of the first remote boot client requesting additional files from the network file system over the first port configured in the second mode. The request for remote boot in the receiving step may be carried out according to the Preboot Execution Environment (PXE) standard client-server interface. A step of the first trunking aware switch receiving traffic from the first remote boot client may be carried out, the received traffic including frames comprising VLAN tags specifying one of the plurality of VLANs. The selected files in the receiving step may enable the first remote boot client to create a RAM disk that is configured to be mounted as a root file system from to enable programs to be run from the mounted RAM disk. The switched network may include a second remote boot client that is coupled to a second trunking aware switch, the second trunking aware switch being coupled to the first trunking aware switch via ports configured in the second mode that enable the second remote boot client to specify one of the plurality of VLANs in addition to the first predetermined native VLAN. The method may further include a step of the second remote boot client requesting remote boot on the first predetermined native VLAN and receiving selected files from the remote boot server, across both first and second trunking aware switches, on the first predetermined native VLAN via the ports configured in the second mode.
According to yet another embodiment, the present invention is a machine-readable medium having data stored thereon representing sequences of instructions which, when executed by a first trunking aware switch, causes said first trunking aware switch to enable remote booting of a first remote boot client in a switched network defining a plurality of native virtual local area networks (VLANs) and including a first remote boot client and a remote boot server, by performing the steps of setting a first port of the first trunking aware switch to a first mode in which traffic received on the first port set in the first mode is directed to a first predetermined native VLAN of the plurality of VLANs; receiving a request for remote boot from the first remote boot client on the first port of the first trunking aware switch, the first port being set in the first mode; directing the request for remote boot from the first trunking aware switch to a second port of the remote boot server, the second port being configured to receive traffic on the first predetermined native VLAN of the plurality of VLANs; receiving selected files from the remote boot server on the first predetermined native VLAN and forwarding the received files to the first remote boot client on the first predetermined native VLAN, the selected files being operative to enable the first remote boot client to initiate loading and booting a selected operating system, and switching the first port of the first trunking aware switch from the first mode to a second mode that enables the first remote boot client to specify one of the plurality of VLANs and to send traffic to the first trunking aware switch on the specified one of the plurality of VLANs.
The switched network may be 802.1q compliant, for example. The switched network may further include a network file system coupled to the switch, and the method may further include a step of the first remote boot client requesting additional files from the network file system over the first port configured in the second mode. The request for remote boot in the receiving step may be carried out according to the Preboot Execution Environment (PXE) standard client-server interface, for example. A step of the first trunking aware switch receiving traffic from the first remote boot client may be carried out, the received traffic including frames comprising VLAN tags specifying one of the plurality of VLANs. The selected files in the receiving step may enable the first remote boot client to create a RAM disk that is configured to be mounted as a root file system from to enable programs to be run from the mounted RAM disk. The switched network may include a second remote boot client that is coupled to a second trunking aware switch, the second trunking aware switch being coupled to the first trunking aware switch via ports configured in the second mode that enable the second remote boot client to specify one of the plurality of VLANs in addition to the first predetermined native VLAN. The method may further include a step of the second remote boot client requesting remote boot on the first predetermined native VLAN and receiving selected files from the remote boot server, across both first and second trunking aware switches, on the first predetermined native VLAN via the ports configured in the second mode.
As also shown in
By configuring the additional ports 210 in a non-trunking mode, when the remote boot client 204 (such as a PXE or equivalent client, for example) broadcasts a DHCP request to the destination address 255.255.255.255 to port 210 (now configured in access mode that does not require a VLAN tag), the request sent to the port 210 of the trunking aware switch 202 (configured for the first predetermined native VLAN—such as VLAN 999) will also be visible to port 226 on the trunking aware switch 202 and will also be visible to the remote boot server 206 on port 222, which is also natively configured for VLAN 999. More particularly, the Ethernet traffic sent out by the remote boot client 204 to the additional port 210 on the trunking aware switch 202 will be visible only to ports (210, 226 and 22) having the same VLAN ID number—that is, VLAN 999. The remote boot server 206 also has an additional port or ports 222 configured for VLAN 999 and will see, therefore, the remote boot client's DHCP request broadcasted to 255.255.255.255 on its VLAN 999 port, even through the DHCP request itself does not include a VLAN tag specifically identifying VLAN 999. Alternatively, the initial DHCP discover request may be sent to port 212 of the trunking aware switch, which may be coupled to the remote boot client 204 via a secondary NIC, as shown at 220.
The remote boot server 206 may then negotiate with the remote boot client 204 on VLAN 999 and transmit thereto the files (e.g., the kernel and an Initrd file, among other possibilities) necessary for the remote boot client 204 to initiate the loading and remote booting of its operating system. Moreover, the remote boot client 204, after it has remotely loaded and booted its operating system, may be configured to communicate on any VLAN ID number, such as, for example, VLAN 900. The remote boot client 204 (PXE client, for example) may then access the Network File System 208 over VLAN 900 over a trunking port 214 of the trunking aware switch.
The additional port 210 of the trunking aware switch 202 may then be configured to switch to trunking mode (dot1q mode) in which the frames must include a reference to the target network. The same port 210, therefore, may be configured in access mode (promiscuous mode) to be restricted to VLAN 999 to allow for remote booting and then switched to trunking mode (dot1q mode) to enable the Ethernet packet traffic itself to dictate to which network (VLAN number) each frame should be switched. In the absence of such an additional port 210 on the switch 202 and the port 222 on the remote boot server 206, the trunking aware switch 202 would not “know” to which network to route the DHCP request, as the 255.255.255.255 lacks a VLAN ID number (such as a VID number), as it would have received the DHCP request on a trunking (e.g., “dot1q”) port—i.e., one that requires an identification of the target VLAN in the frames it receives.
According to this embodiment, all ports within the system 300 may be dot1q-enabled ports, with the exception of the ports of the remote boot server(s), and the port(s) of the Network File System (NFS). In turn, this entails that all packets to and from the first and second remote boot clients 204, 314 should include the predetermined VLAN tag in both the first and second modes. The packets exchanged between the trunk ports 304, 308 between the first and second trunking aware switches 302, 306 should also include the predetermined VLAN tag to identify the VLAN number on which to send and receive packets.
From the foregoing, it may be appreciated that embodiments of the present invention enable remote booting of remote boot clients within a trunking environment complying with protocols such as 802.1q or ISL, for example. Utilizing embodiments of the present invention, the number of cables and NICs that are required decreases, as only a single NIC/cable combination and a single NIC/backup cable may be necessary to both remote load and boot the remote boot client 204 and to access a plurality of VLANs from the remotely booted clients.
Embodiments of the present invention are related to the use of computer system and/or to a plurality of such computer systems to enable methods and systems for enabling remote booting of a remote boot client in a switched network defining a plurality of VLANs. According to one embodiment, the methods and systems described herein may be provided by one or more computer systems in response to processor(s) executing sequences of instructions contained in memory. Such instructions may be read into memory from a computer-readable medium, such as a data storage device. Execution of the sequences of instructions contained in memory causes the processor(s) of the trunking aware switch to perform the steps and to have the functionality described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.
While the foregoing detailed description has described preferred embodiments of the present invention, it is to be understood that the above description is illustrative only and not limiting of the disclosed invention. Those of skill in this art will recognize other alternative embodiments and all such embodiments are deemed to fall within the scope of the present invention. Thus, the present invention should be limited only by the claims as set forth below.
Wong, Steven, Chandar, C. Brem, Au, Kin
Patent | Priority | Assignee | Title |
7969888, | Apr 27 2007 | Futurewei Technologies, Inc. | Data communications network for the management of an ethernet transport network |
8140654, | Apr 27 2007 | Futurewei Technologies, Inc. | Verifying management virtual local area network identifier provisioning consistency |
Patent | Priority | Assignee | Title |
6810478, | Dec 12 2000 | International Business Machines Corporation | System for remote booting of muntliple operating systems using chained bootstrap mechanism in a network |
7080134, | Jun 29 2001 | Intel Corporation | Systems and methods for software distribution and management |
7350068, | Apr 22 2005 | GOOGLE LLC | Server blade network boot method that minimizes required network bandwidth |
7418588, | Dec 31 2003 | Jade Quantum Technologies, Inc. | Method and apparatus for redirecting a local boot request to a remote location |
20030018763, | |||
20030097422, | |||
20040081104, | |||
20040210623, | |||
20050091387, | |||
20050144431, | |||
20060075217, | |||
20060253565, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
May 07 2006 | CHANDAR, C BREM | Oracle International Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017889 | /0745 | |
May 12 2006 | WONG, STEVEN | Oracle International Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017889 | /0745 | |
May 12 2006 | AU, KIN | Oracle International Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 017889 | /0745 | |
May 16 2006 | Oracle International Corporation | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Aug 29 2012 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Sep 15 2016 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Sep 17 2020 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Mar 31 2012 | 4 years fee payment window open |
Oct 01 2012 | 6 months grace period start (w surcharge) |
Mar 31 2013 | patent expiry (for year 4) |
Mar 31 2015 | 2 years to revive unintentionally abandoned end. (for year 4) |
Mar 31 2016 | 8 years fee payment window open |
Oct 01 2016 | 6 months grace period start (w surcharge) |
Mar 31 2017 | patent expiry (for year 8) |
Mar 31 2019 | 2 years to revive unintentionally abandoned end. (for year 8) |
Mar 31 2020 | 12 years fee payment window open |
Oct 01 2020 | 6 months grace period start (w surcharge) |
Mar 31 2021 | patent expiry (for year 12) |
Mar 31 2023 | 2 years to revive unintentionally abandoned end. (for year 12) |