WO2016099530A1

WO2016099530A1 - Electronic form to collect a client requirement associated with network traffic management

Info

Publication number: WO2016099530A1
Application number: PCT/US2014/071365
Authority: WO
Inventors: Silvano DA ROS
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2014-12-19
Filing date: 2014-12-19
Publication date: 2016-06-23

Abstract

Some examples provide a method where an electronic form is provided, which may be used to collect a set of client requirements associated with network traffic management. The set of client requirements collected by the electronic form is received and validated based on a set of checks. The set of client requirements can include a client requirement associated with a network traffic management device using a particular virtual network address, and the set of checks can include determining whether the particular virtual network address is available for use by the network traffic management device.

Description

ELECTRONIC FORM TO COLLECT A CLIENT REQUIREME T

ASSOCIATED W!TH NETWORK TRAFFIC MA AGEME T

BACKGROUND

[0001] Datacenters generally include one or more pools of server computing devices (hereafter, server pools) capable of supporting (e.g., providing) various computer services, such as cloud services and web-based applications. Server pools not only enable scalability in providing such computer services (e.g., by providing a pool of computer resources that can be utilized according to client demand), but also ensure reliability in providing such computer services (e.g., provide redundancy in the event that a member of the server pool is incapacitated). At present, network traffic management techniques, such a load balancing, application acceleration, caching, network traffic shaping, and data compression, are commonly utilized in the delivery computer services supported by server pools. The emergence of application delivery networks (ADNs) and their respective application delivery controllers (ADC) devices has improved implementation and performance of network traffic management functions for server pools.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Certain examples are described in the following detailed description in reference to the following drawings.

[0003] FIG. 1 illustrates an example environment including an example client system in communication with an example server system, and an example network traffic management system in communication with the example server system.

[0004] FIG. 2 illustrates an example server computing device.

[0005] FIGs. 3-8 illustrate example methods for receiving and validating a client requirement for network traffic management.

[0008] FIG. 7 presents a screenshot of an example electronic form used by examples described herein. DETA!LED DESCFUPT!GM OF SPEOF!C EXAMPLES

[0007] This disclosure describes example techniques for collecting a client's one or more requirements (hereafter, client requirements) for a network traffic management system, such as an application delivery controller (ADC) device associated with an application delivery network (ADN), A network traffic management system, such as an ADC device, can provide various network traffic-related functions for a pool of server computing devices, including load balancing, application acceleration, caching (e.g., HTTP caching), network traffic shaping, data compression (e.g., HTTP-content compression), secure sockets layer (SSL) acceleration, content switching (e.g., layer 4-7 switching), and the like. As described herein, the functions provided by a network traffic can assist in implementation of high availability (HA), scalability, or both with respect to computing services provided by a pool of servers, including managed computing services for clients. By facilitating or assisting in the collection of requirements for a network traffic management system, various examples disclosed herein can assist in the configuration of the network traffic

management system. Certain examples can reduce or otherwise prevent errors during collection of client requirements associated with a network traffic management system. Further, particular examples can improve the process of submitting or translating a client requirement for implementation at a network traffic management system.

[0008] As used herein, a client with respect to a network traffic

management system will be understood to represent a user or a group of users (e.g., associated with an organization, such as a small or large company) that intends to receive, use, or otherwise benefit from a computing service provided by a server pool through a network traffic management system. As used herein, an engineer will be understood to represent a user managing or assisting in the configuration of a network traffic management system.

[0009] In some examples, an electronic form is provided and a set of client requirements, associated with network traffic management (e.g., associated with a network traffic management system, such as an ADC) and collected by the electronic form, is received. Thereafter, the set of client requirements can be validated based on a set of checks, and the set of client requirements can be validated before they are implemented at a network traffic management system. Depending on the example, the set of checks can reduce or eliminate the chances of the set of client requirements including errors or causing issues when implemented at a network traffic management system. The set of checks can include, for example, a check that prevents duplication of use of a virtual network address (e.g., virtual Internet-protocol [IP] address), a constraint check of a client requirement based on a dependency, and a status check of an application provided or supported by a server pool through a network traffic management system (e.g., network traffic for the application passes between the server pool and a client system passes through the network traffic management system).

[0010] FIG. 1 illustrates an example environment 100 including an example client system in communication with an example server system, and an example network traffic management system in communication with the example server system, in particular, environment 100 includes a client system 102 in communication with a server system 104 over a communications network 108, and a network traffic management system 106 in communication with the server system 104 over the communications network 108. As shown, the server system 104 includes an electronic form module 120, a client requirement receiving module 122, a client requirement validation module 124, a setting generation module 126, and a server communications module 128.

[0011] Depending on the example, the client system 102 may comprise a desktop, laptop, a hand-held computing device (e.g., personal digital assistants, smartphones, tablets, etc.), a workstation, and the like. Additionally, depending on the example, the server system 104 may comprise one or more servers, which may be operating on, or implemented, using one or more cloud-based resources, such as a System-as-a-Service (SaaS), Piatform-as-a-Service (PaaS), or !nfrastructure-as-a-Service (laaS). In various examples, the components or the arrangement of components in the environment 100 may differ from what is depicted in FIG. 1 . For instance, the server system 104 can include more or less components than those depicted in FIG. 1 . [0012] As used herein, modules and other components of various examples may comprise, in whole or in part, machine-readable instructions or electronic circuitry. For instance, a module may comprise computer-readable instructions executable by a processor to perform one or more functions in accordance with various examples described herein. Likewise, in another instance, a module may comprise electronic circuitry to perform one or more functions in accordance with various examples described herein. The elements of a module may be combined in a single package, maintained in several packages, or maintained separately.

[0013] The communications network 108 permits data to be communicated between the client system 102, the server system 104, and the network traffic management system 106 in accordance with various examples described herein, in some examples, the communications network 108 may comprise one or more local or wide-area communications networks, such as the internet, WiFi networks, cellular networks, private networks, public networks, and the like.

[0014] The client system 102 may be utilized by a client user to receive an electronic form, use the electronic form to define or otherwise modify a client requirement for the network traffic management system 106, and submit the client requirement to the server system 104. For some examples, the electronic form comprises a web page, post-script document (e.g., tillable PDF), or some other electronic document accessible by a client user at the client system 102. The electronic form may be in the form a questionnaire that a client user will complete to facilitate proper configuration of the network traffic management system 106. Additionally, the electronic form may receive at least one client requirement as an attribute-value pair. Such an attribute-value pair may represent an answer to the questionnaire. Through the electronic form, the client user may submit to the server system 104 a set of client requirements for the network traffic management system 106 and, in turn, the server system 104 can provide the client user with feedback on the set of client requirements (e.g., validation results) before the set of client requirements is implemented to the network traffic management system 106. [0015] Referring now to the server system 104, the electronic form module 120 may facilitate providing an electronic form described herein to the client system 102. in some examples, the electronic form module 120 generates an electronic form according to a definition (e.g., HTML code) prepared by an engineer (e.g., network traffic engineer familiar with the network traffic management system 106). Additionally, in some examples, the electronic form module 120 provides an electronic form comprises an electronic document, such a web page, Microsoft® Word® document, or a post-script document. Depending on the example, the set of client requirements collected by the electronic form (provided by the electronic form module 120) may include a client requirement generally associated with network traffic management or one particularly associated with the network traffic management system 106.

[0016] For various examples, a client user at the client system 102 enters user input with respect to the electronic document, and at least some of the user input relates to or results in the collection of a client requirement for the network traffic management system 106. Accordingly, the electronic form can comprise a set of input elements (e.g., graphical user interface elements) that relate to the collection of client requirements for the network traffic management system 106. For instance, the electronic form can comprise various types of input elements, such as text fields (e.g., ASCII field), listings of static values from which the user can select (e.g., drop-down menu), buttons, and displays (e.g., for displaying default values or validation feedback), which are configured to collect a set of client requirements for the network traffic management system 106. Depending on the example, the electronic document may collect at least some of the set of client requirements as attribute-value pairs.

[0017] The electronic form may obtain from a client user various client requirements for the network traffic management system 106. Example client requirements include, without limitation, those relating to: a device pairing (e.g., a pairing between an ADC device and a particular client or business); configuration partitions on the network traffic management system 106 (e.g., configuration partition available on an ADC device); a domain name (e.g., fully qualified domain name [FQDN]); virtual network address allocation (e.g., virtual Internet protocol [IP] addresses available on an ADC device); port address (e.g., port associated with a FQDN); user universal resource locator (URL); redirection (e.g., redirection URL); SSL connections (e.g., no SSL, SSL pass-through, SSL termination with or without re-initiation, SSL certificate requirements); load balancing (e.g., none, load balancing method, cookie-based or source IP-based persistence); monitoring (e.g., transport control protocol [TCP]-based, hyper-text transport protocol [HTTPj-based, or secure HTTP [HTTPSj-based monitoring, monitoring interval, or monitoring timeout); and members of a server pool (e.g., add or remove servers to the server pool based on their network address and port number).

[0018] The client requirement receiving module 122 may facilitate receiving a set of client requirements collected by the electronic form provided by the electronic form module 120. The client requirement receiving module 122 may, for instance, receive the set of client requirements from the client system 102 as a data set, which the client system 102 may have produced based on a client user's input to the electronic form. Alternatively, the client system 102 may submit the set of client requirements to the server system 104 by storing client user's inputs to the electronic form, and sending the resulting electronic form back to the server system 104 for further processing. Subsequently, the server system 104 may extract the set of client requirements from the returned electronic form, and the client requirement receiving module 122 may receive the extracted set of client requirements. Depending on the example, the set of client requirements received by client requirement receiving module 122 may include a client requirement generally associated with network traffic management or one particularly associated with the network traffic management system 106. As described herein, at least one client requirement, in the set of client requirements received by client requirement receiving module 122, may be in the form of an attribute-value pair.

[0019] The client requirement validation module 124 may facilitate validating a set of client requirements based on a set of checks. According to various examples, the set of checks permit the client requirement validation module 124 to reduce or otherwise prevent errors during collection of client requirements associated with the network traffic management system 106. For instance, the set of checks may determine whether a particular virtual network address (e.g., virtual IP address) associated with a client requirement (e.g., specified by the client requirement) is available for use by the network traffic management system 106. Such checks may prevent or reduce the changes of duplication of use of the particular network address. The set of checks may determine a particular virtual network address unavailable if, for example: the particular virtual network address is currently requested for use by another network device (e.g., another network traffic management system has an outstanding request to the server system 104 to use of the virtual network address through); the particular virtual network address is currently registered with a network address management system (e.g., a dynamic host control protocol [DHCP] system) for use by another network device; or another network device responds to a network query sent to the particular network address (e.g., whether another network device responds to a ping transmitted to the particular network address by the server system 104).

[0020] The set of checks may determine whether a first client requirement violates a constraint based on a second client requirement that is related to (e.g., dependent on) the first. For example, the set of checks may determine whether a fully qualified domain name (FQDN) associated with (e.g., specified by) a first given client requirement resolves to a virtual network address (e.g., virtual IP address) associated (e.g., specified by) with a second given client requirement. By perform such constraint checks, conflicts between two or more client requirements can be avoided or addressed before they are implemented at the network traffic management system 106.

[0021] Further, the set of checks may determine the status (e.g., network status) of a computing service provided, or supported, by a server pool through the network traffic management system 106 (e.g., network traffic for the computing service passes between the server pool and a client system through the network traffic management system 106). For instance, the set of checks may determine the health status of a particular web-based application provided by a server pool through the network traffic management system 106. The set of checks may determine, for instance, whether the particular web-based application is active (e.g., operating and responsive) or inactive (e.g., non- responsive).

[0022] Depending on the example, the set of checks may determine whether a (server) member of a server pool is online (or offline) by performing a network interrogation of the server using a network address associated with the member. The network address associated with the member may be specified by the client requirements provided through the electronic form provided by the electronic form module 120.

[0023] In some examples, a client user at the client system 102 can be informed regarding any issues or errors detected by the client requirement validation module 124. For instance, the issue or error may be displayed as validation feedback on the electronic form used to collect the set of client requirements from the client user at the client system 102. In this way, the validation feedback permits the client user to address (e.g., correct) the client requirement in the electronic form causing the issue or error.

[0024] The setting generation module 128 may facilitate generation of a set of settings for the network traffic management system 106 based on the set of client requirements received by the client requirements receiving module 122. For various embodiments, the set of settings is generated based on the set of client requirements after the set of client requirements is validated by the client requirement validation module 124. Subsequent to validation, some examples translate the set of client requirements to a set of settings using a configuration mapping or logic, which may be specifically associated with the network traffic management system 108. The set of settings may comprise engineering work orders that an engineer can implement (e.g., manually) at the network traffic management system 106. Additionally, or alternatively, the set of settings may comprise a script including commands (e.g., executable at a command line input [CLI]) for implementing the set of client requirements at the network traffic management system 108 (e.g., when the script is executed by the network traffic management system 106). Example commands utilized in a script can include, without limitation, those relating to creation of a SSL certificate, those relating to configuring monitoring a member of a server pool, those relating to configuring load balancing for a server pool, and those relating to configuring redirection.

[0025] The server communications module 128 may facilitate communication between the server system 104 and the client system 102 over the communications network 108, and between the server system 104 and the network traffic management system 108. For instance, the server communications module 128 may facilitate the server system 104 sending an electronic form described herein to the client system 102, or may facilitate the server system 104 receiving from the client system 102 a set of client requirements (e.g., as collected at the client system 102 by the electronic form). In another instance, the server communications module 128 may facilitate the server system 104 obtaining from the network traffic management system 108 a current setting of the network traffic management system 108, or may facilitate the server system 104 sending the network traffic management system 106 a set of settings to implement a set of client requirements at the network traffic management system 106.

[0026] FIG. 2 illustrates an example server computing device 200. As shown, the server computing device 200 includes a computer-readable medium 202, a processor 204, and a communications interface 208. In various examples, the components or the arrangement of components of the server computing device 200 may differ from what is depicted in FIG. 2. For instance, the server computing device 200 can include more or less components than those depicted in FIG. 2.

[0027] The computer-readable medium 202 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. For example, the computer-readable medium 202 may be a Random Access Memory (RAM), an Electrically-Erasable Programmable Readonly Memory (EEPROM), a storage drive, an optical disc, or the like. The computer-readable medium 202 can be encoded to store executable instructions that cause the processor 204 to perform operations in accordance with various examples described herein. In various examples, the computer-readable medium 202 is non-transitory. As shown in FIG. 2, the computer-readable medium 202 includes electronic form providing instructions 208, client requirement receiving instructions 210, and client requirement validation instructions 212.

[0028] The processor 204 may be one or more central processing units (CPUs), microprocessors, or other hardware devices suitable for retrieval and execution of one or more instructions stored in the computer-readable medium 202. The processor 204 may fetch, decode, and execute the instructions 208, 210, and 212 to enable the server computing device 200 to perform operations in accordance with various examples described herein. For some examples, the processor 204 may include one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of the instructions 208, 210, and 212.

[0029] The electronic form providing instructions 208 may cause the processor 204 to provide a client computing device with an electronic form, which a user at the client computing device may utilize to input a set of client requirements for (e.g., to be implemented at) a network traffic management system. The client requirement receiving instructions 210 may cause the processor 204 to receive a set of client requirements collected by an electronic form provided by the processor 204 as a result of the electronic form providing instructions 208. The client requirement validation instructions 212 may cause the processor 204 to a set of client requirements received by the processor 204 as a result of the client requirement receiving instructions 210.

[0030] FIG. 3 illustrates an example method 300 for receiving and validating a client requirement for network traffic management. Although execution of method 300 is described below with reference to the server system 104 of FIG. 1 , other suitable systems or devices for execution of method 300 can be possible, such as the server computing device 200 of FIG. 2. The method 300 may be implemented in the form of executable instructions stored on a computer- readable medium or in the form of electronic circuitry.

[0031] In FIG. 3, the method 300 begins at block 302 with the server system 104 receiving a set of client requirements for the network traffic management system 106, where the set of client requirements is collected by way of an electronic form. As described herein, the set of client requirements may be collected! by an electronic form provided by the server system 104 to the client system 102, thereby permitting the client user at the client system 102 to enter user input with respect the electronic form. As also described herein, the set of client requirements can include at least one client requirement in the form of an attribute-value pair.

[0032] At block 304, the server system 104 validates the set of client requirements, received at block 302, for a virtual network address (e.g., virtual IP address). The virtual network address may be one associated with (e.g., specified by) a client requirement in the set of client requirements. In particular, the server system 104 may validate the set of client requirements for the virtual network address by determining whether the virtual network address (e.g., virtual IP address) is available for use by the network traffic management system 106. As described herein, a particular virtual network address may not be available if, for example, if is currently requested for use by another network device, it is currently registered with a network address management system for use by another network device, or another network device responds to a network query sent to the particular network address by the server system 104.

[0033] FIG. 4 illustrates an example method 400 for receiving and validating a client requirement for network traffic management. Although execution of method 400 is described below with reference to the server system 104 of FIG. 1 , other suitable systems or devices for execution of method 400 can be possible, such as the server computing device 200 of FIG. 2. The method 400 may be implemented in the form of executable instructions stored on a computer- readable medium or in the form of electronic circuitry.

[0034] In FIG. 4, the method 400 begins at block 402, with the server system 104 receiving a set of client requirements for the network traffic management system 108, where the set of client requirements is collected by way of an electronic form. Block 402 may be similar to block 302 of method 300, which is described above with respect to FIG. 3.

[Θ035] At block 404, the server system 104 validates the set of client requirements, received at block 402, for a network status of a server. The server may be one associated with a client requirement in the set of client requirements, and the network status of the server, which may include a network status indicating that the server is aiive, down (e.g., non-responsive), or is slow to respond over the network. As described herein, the network status of the server may be determined by the server system 104 performing a network interrogation of the server.

[0036] FIG. 5 illustrates an example method 500 for receiving and validating a client requirement for network traffic management. Although execution of method 500 is described below with reference to the server system 104 of FIG. 1 , other suitable systems or devices for execution of method 500 can be possible, such as the server computing device 200 of FIG. 2. The method 500 may be implemented in the form of executable instructions stored on a computer- readable medium or in the form of electronic circuitry.

[0037] In FIG. 5, the method 500 begins at block 502 with the server system 104 providing an electronic form to the client system 102. As described herein, the electronic form may comprise a web page, post-script document, or some other electronic document accessible by a client user at the client system 102. As noted herein, through the electronic form, a client user at the client system 102 can enter a set of client requirements associated with network traffic management. The client system 102 may submit the set of client requirements collected by the electronic form as a data set produced by user input received with respect to the electronic form. Alternatively, the client system 102 may submit the set of client requirements to the server system 104 by storing client users inputs to the electronic form, and then sending the resulting electronic form back to the server system 104 for further processing.

[0038] At block 504, the server system 104 receives a set of client requirements for the network traffic management system 108, whereby the set of client requirements received is collected by way of the electronic form provided at block 502. Block 504 may be similar to block 302 of method 300, which is described above with respect to FIG. 3.

[Θ039] At block 506, the server system 104 validates the set of client requirements received at block 302. As described herein, the server system 104 may validate the set of client requirements based on a set of checks, which may permit the server system 104 to reduce or otherwise prevent errors during collection of client requirements associated with the network traffic management system 106. As noted herein, the set of checks can include validating the set of client requirements for a virtual network address, or for a network status of a server. The set of checks may also include determining whether a first client requirement violates a constraint based on a second client requirement that is related to (e.g., dependent on) the first.

[0040] FIG. 6 illustrates an example method 600 for receiving and validating a client requirement for network traffic management. Although execution of method 600 is described below with reference to the server system 104 and the network traffic management system 106 of FIG. 1 , other suitable systems or devices for execution of method 600 can be possible, such as the server computing device 200 of FIG. 2. The method 600 may be implemented in the form of executable instructions stored on a computer-readable medium or in the form of electronic circuitry.

[0041] In FIG. 6, the method 600 begins at block 602, with the server system 104 receiving a set of client requirements for the network traffic management system 106, where the set of client requirements is collected by way of an electronic form. Block 602 may be similar to block 302 of method 300, which is described above with respect to FIG. 3.

[0042] At block 604, the server system 104 validates the set of client requirements received at block 302. Block 604 may be similar to block 506 of method 500, which is described above with respect to FIG. 5.

[0043] At block 606, the server system 104 generates a set of settings for the network traffic management system 106 based on the client requirement validated at block 604. As described herein, the set of settings may be generated subsequent to a successful validation of the set of client requirements. Depending on the example, the set of settings may comprise engineering work orders that an engineer can implement (e.g., manually) at the network traffic management system 106. Additionally, or alternatively, the set of settings may comprise a script including commands (e.g., executable at a command line input [CU]) for implementing the set of client requirements at the network traffic management system 108,

[0044] FIG. 7 presents a screenshot of an example electronic form 700 that may be used by various examples described herein. For certain examples, the electronic form 700 is provided by the electronic form module 120 of the server system 104, As shown, the electronic form 700 includes various types of input elements to collect a set of client requirements associated with network traffic management. With respect to general client requirements for a network traffic management system (e.g., ADC), the input elements include a drop-down menu to select ADC pair and a drop-down menu to select a configuration partition. With respect to URL-related client requirements for accessing a computing service through the network traffic management system, the input elements include text fields for specifying a PGDN, a port, a user URL, and a redirect URL, and a dropdown menu for select a SSL option. The input elements include text fields for specifying virtual IP subnet address and a virtual IP address. In regard to client requirements relating to SSL certificate, the input elements include text fields and drop-down menus for specifying organizational information for certificate signing requests. With respect to client requirements relating to server pool members, the input elements include text fields for specifying an IP address and a port number for a server member to be added to a server pool that provides a computing service through the network traffic management system. For client requirements relating to load balancing, the input elements include text fields for specifying monitoring parameters (e.g., timeout interval, etc.) and drop-down menus to specify load balancing operation (e.g., load balancing persistence and load balancing method).

[0045] After a client user submits a set of client requirements through the electronic form 700, it may be validated in accordance with various examples described herein. For issues or errors detected during validation (e.g., detected by the client requirement validation module 124 of the server system 104), the detected issues or errors may be presented on the electronic form 700 as feedback. In FIG. 7, the electronic form 700 includes an "Action Window" in which to display a listing of errors or issues detected in the set of client requirements collected through the electronic form 700. Other examples may use additional or alternative methods for displaying validation feedback, on an electronic form, for client requirements.

[0046] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However,

implementations may be practiced without some or all of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

1 . A method, comprising:

providing an electronic form;

receiving a set of client requirements associated with network traffic management, wherein the set of client requirements is collected by the electronic form; and

validating the set of client requirements based on a set of checks, wherein the set of client requirements includes a client requirement associated with a network traffic management device using a particular virtual network address, and the set of checks includes determining whether the particular virtual network address is available for use by the network traffic management device.

2. The method of claim 1 , wherein the network traffic management device is an application delivery controller (ADC).

3. The method of claim 1 , wherein the electronic form collects at least one client requirement, in the set of the client requirements, as an attribute-value pair.

4. The method of claim 1 , wherein determining whether the particular virtual network address is available for use by the network traffic management device comprises determining whether the particular virtual address is not currently requested for use by another network device.

5. The method of claim 1 , wherein determining whether the particular virtual network address is available for use by the network traffic management device comprises determining whether the particular virtual address is not registered with a network address management system for use by another network device.

8. The method of claim 1 , wherein determining whether the particular virtual network address is available for use by the network traffic management device comprises determining whether another network device responds to a network query sent to the particular virtual network address.

7. The method of claim 1 , wherein the particular virtual network address comprises a virtual Internet Protocol (IP) address.

8. The method of claim 1 , comprising generating, in response to the set of client requirements being valid, a set of settings for the network traffic management device based on the set of client requirements, wherein the set of settings implements the set of client requirements at the network traffic management device.

9. The method of claim 8, wherein the set of settings includes a set of engineering work orders.

10. The method of claim 1 , wherein the set of checks includes validating a first requirement in the set of client requirements against a second requirement in the set of client requirements, and a dependency exists between the first requirement and the second requirement.

1 1 . A computer system, comprising:

a processor; and

a memory including instructions being executable by the processor to: receive a set of client requirements associated with network traffic management collected by an electronic form; and

12. A non-transitory computer readable medium having instructions stored thereon, the instructions being executable by a processor of a computing device to:

provide an electronic form; receive a set of client requirements associated with network traffic management, wherein the set of ciient requirements is coliected by the electronic form; and

validate the set of client requirements based on a set of checks, wherein the set of client requirements includes a ciient requirement associated with a server, and the set of checks includes determining a network status of the server.

13. The non-transitory computer readable medium of claim 12, wherein to determine the network status of the server, the instructions are executable by the processor to perform a network interrogation of the server using a network address associated with the server.

14. The non-transitory computer readable medium of claim 12, wherein the instructions are executable by a processor to generate, in response to the set of client requirements being valid, a set of settings for a network traffic

management device based on the set of client requirements, and the set of settings implements the set of client requirements at the network traffic management device.

15. The non-transitory computer readable medium of claim 14, wherein the set of settings includes a set of engineering work orders.