Web Based Management of Network Devices

Christopher D. Leidigh American Power Conversion July, 1997

Overview
Since the late 1980s the number of computer networks has been increasing tremendously. Companies are employing larger and more extensive networks that no longer span offices, but countries. These are typically multi-vendor, heterogeneous networks that require extensive network management to insure seamless operation and continuous data flow. The complexity of network management has grown in proportion to these networks as well. Network managers are faced with learning many different tools to manage their networks. While standards do exist such as SNMP (Simple Network Management Protocol), they still require vendor extensions such as GUI snap-ins for network management platforms to be truly useful. Generally network managers must deal with the installation, learning and then training associated with each vendors management application or add-on. Web based management can reduce the installation element and in many cases ease the learning curve associated with managing the various devices. This paper will present ways in which a network device can incorporate management via a web interface either solely or in addition to several other standard methods.

Management Today Using SNMP

The SNMP standard has become the de-facto method of managing network devices. The protocol is simple enough that it can be implemented in small platforms without too much difficulty. SNMP was created in the late eighties for the purpose of providing an industry standard protocol for communicating with network devices. The thought was that as networks grew there needed to be some common method for monitoring, controlling and receiving alerts from disparate devices. This would enable a central Network Management Station (NMS) to monitor all SNMP enabled devices as opposed to having many vendor specific programs. The SNMP management scheme usually consists of an SNMP based NMS such as HPs OpenView as well as network devices with SNMP agents. Each device with an SNMP agent maintains a Management Information Base (MIB). The MIB is the collection of manageable data elements within the SNMP agent. The IETF (Internet Engineering Task Force) has developed the MIB structure to include several standard elements, the inclusion of which makes a device MIB II compatible. The MIB is organized in a hierarchical tree fashion; each branch, or node of the tree, is identified by an Object Identifier (OID). The OID is an integer sequence representing the branches of categories and data nodes contained within. The primary branches of MIB-II defined by the IETF are shown below including three private enterprise branches (vendor specific mibs).

Iso(1) org(3) Dod(6) Internet(1) Directory(1) Mgmt(2) Mib-2(1) System(1) Interfaces(2) At(3) Ip(4) Icmp(5) Tcp(6) Udp(7) Egp(8) Transmission(10) Snmp(11) Experimental(3) Private(4) enterprises(1)

MIB-II Object Tree and Groups

APC (318) 3COM HP

The enterprise branch OID (1.3.6.1.3.4.1) is the branch that contains commercial parts of the MIB. Each vendor has an IETF assigned branch number under which all of that vendors device MIBs would appear. This allows all MIB OIDs to be unique in the world, but managed as one hierarchical tree. When a vendor creates a MIB, he or she is responsible for guaranteeing uniqueness within his or her enterprise branch. The MIB definition is done as a text file in BNF format where each OID definition is given with data types, possible values if applicable, read \

write capability and comments. An NMS can read this file so that it can manage the target SNMP agent. All information in the SNMP standard is represented in the machine independent format of ASN.1 (Abstract Symbolic Notation). All major data types have standard representations including integers, floats, strings, enumerations, OID sequences, IP addresses and others. Utilizing a standard data encoding enables multiple platforms to be able to transfer data values that will be guaranteed to be interpreted correctly. The individual data elements in the tree are refer Communication with an SNMP agent is done through one of four SNMP operation requests in an SNMP PDU (protocol data unit); Get, GetNext, Set and Trap. All SNMP PDUs use UDP (User Datagram Protocol) as their transport protocol thus SNMP is by inheritance an unreliable protocol. Each of the Get, GetNext and Set PDU operations is sent to the SNMP agent requesting either one or more OID values (Get and GetNext) or specifying one or more write values for OIDs (Set). The agent responds with either the data values or an error PDU. The Trap PDU is the only PDU sent asynchronously from the SNMP agent. These are usually alert type messages which the agent sends to a predefined Trap Receiver(s). Typically a central NMS will be setup as an enterprise wide trap receiver to collect and display SNMP traps (alerts) to a network manager. The Community Name field in the PDU is the only built in security in SNMPv1. Each agent can have one or more access communities, each with definable read, write or read and write capability. Every PDU must include the correct community name for access validation. As the community is transmitted as plain text, SNMPv1 has never been considered a highly secure protocol. SNMPv2 attempts to address this and other shortcomings of SNMPv1, but it has never gained wide usage. An NMS usually allows one to drill down into a devices MIB to the particular OID of interest. At this point the data can be read or set by the user assuming the correct community access names are used. NMS platforms will also have alarm windows that show the incoming SNMP traps either per device or globally. While these methodologies exploit the general elements of SNMP they are not always the easiest ways in which to manage a device. NMS platforms are not usually userfriendly. One answer to the above problem has been vendor snap-ins to platforms such as OpenView. HP offers an API to vendors so that they may use the underlying SNMP engine in OpenView while providing vendor GUIs that can have graphical elements such as buttons, knobs, gauges and graphs. This gives the user the possibility of using a visual interface as opposed to a text based tree walk necessary with straight MIB bowsers.

Shortcomings of SNMP The SNMP protocol was meant to simple, hence the S. Eventually simple things usually have restrictions that require extensions or new standards. Some of SNMPs problems are that it is not always easy to use and it can be very expensive. NMS platforms are particularly expensive and not

very easy to use. While large corporations capable of paying for both the equipment, software and user training required, can afford this, most small users cannot. Managing devices using an SNMP browser can be very painful. Most users demand vendor GUI snap-ins. These snap-ins must be created by the vendor for each NMS platform and each OS. The version set becomes large very quickly, the maintenance enormous. While this may be a vendor problem it becomes a user problem when one has to match OS, NMS and all vendors snap-ins. Installation of these snap-ins and version matching are also necessary. Web Based Management Overview A new trend in network management is using the web protocols (HTTP, HTML, Java etc) as a management methodology. By placing a web server (an HTTP deamon) in a network device, the device can serve up web pages to any standard web browser such as Navigator or Internet Explorer. These pages become the GUI interface to the device. While the above concept appears simple and perhaps not that revolutionary, the implications are deeper then they may appear. By placing the GUI within the device itself two important things happen, the device is now self contained and need not be matched with a corresponding version of a snap-in and no NMS platform is needed for monitoring and controlling the device. The first point also has the related advantage of eliminating multi-platform vendor development. The Web browser and Internet usage is also ubiquitous enough that it is possible for almost anyone to do network management with little or no training. The HTTP protocol and HTML HTTP (HyperText Transport Protocol) was created in the early nineties as a method of linking scientific documents on the Internet. The initial specification allowed text documents to include references to other documents either on the same site as the base document or on any other accessible site. From a user perspective the base document would have a word or phrase underlined or in bold indicating that it was a hyper-link. If the user selected the word the browser would load the target document from the indicated link. The explosion of the web came as graphical browsers such as Mosaic emerged, that could also show images and different text styles. Today HTML (HyperText Markup Language) has been expanded to include fonts, frames, audio support, animated gifs and other elements. The HTTP protocol HTTP is a client-server application protocol that utilizes TCP for its transport. The HTTP (or web) server has a well known port number of (80). Client applications such as the Netscape Navigator make TCP open requests to this port to initiate a session. HTTP is a client driven protocol meaning that all communications are initiated at the client end. This aspect is evolving somewhat, see new trends. HTTP has three basic operations, Get, Head and Post. These operations and all HTTP communication are done in plain text or base-64 encoded binary. Once a server has accepted a connection it expects one of the three commands followed by supporting parameters. The server then issues a response and closes the connection. Each operation is thus considered singular and stateless. Object addressing is done using Universal Resource Locators (URLs) [RFC 1808].

GET Operation Retrieves an object (referenced by URL) from the currently open HTTP server. HEAD Operation Retrieves the header and response information only (the server does not return the object body to the requestor. POST Operation Passes parameters or data within a request to be processed by the referenced URL. The server is expected to provide a response including body content.

The basic Get, Head and Post operations can contain an optional URL which is effectively the address of the desired page or object to be retrieved from the server similar to a path\file specification. The HTTP version is also usually included for HTTP v1.0 and above: GET Error! Bookmark not defined. HTTP/1.0 crlf Or HEAD /sample/sample.htm HTTP/1.0 crlf The crlf pair is necessary to terminate the request and cause the server to issue its response. A full request can also include request headers using field-name : field-value pairs separated by crlf pairs. Some standard request header fields: Authorization If-Modified-Since Referrer Used to identify a requestor for security Only return content newer than indicated date URL of referring resource

An HTTP server responds with a 3 digit result code and a reason string. The first digit of the response code identifies the response type category, ie. 1xx = informational, 2xx = OK, 3xx = redirection, 4xx = client error and 5xx = server error. The optional reason string is an English description of the result or problem. Standard Result Codes 200 201 202 204 301 302 304 400 OK Created Accepted No Content Moved Permanently Moved Temporarily Not Modified Bad Request

401 403 404 500 501 502 503

Unauthorized Forbidden Not Found Internal Server Error Not Implemented Bad gateway Service Unavailable

Response headers and response body content may also follow (In the case of the GET only). The server response headers identify to the client body content type, encoding, length and other support information that usually includes server type, the last object modification date. The response header follows the same format as the request header using field-name : fieldvalue pairs separated by crlf pairs. MIME Content and HTML Most web servers will contain a collection of web pages. Static web pages (those not created dynamically) will be text files of HTML (HyperText Markup Language) [RFC 1866] page descriptions. HTML is the primary MIME type used for web pages. The HTML specification continues to grow rapidly as Web browsers implement new functionality and GUI components. HTML is a collection of textual tag definitions that tell a browser how to display a page. It is up to the browser to correctly display the information as per the constraints and capabilities of the system that the browser is running on. In this sense the HTML page description is loose definition. Different browsers on different systems will probably all render the same page slightly differently, fonts, font sizes, colors etc.. A simple Hello World example page would consist of the following: <html> <body> Hello World </body> </html> By placing all of the creation demand on the browser side the server device need only store the page definition text. All of the GUI elements are handled by the browser clients. The drawback to this system is control, the browser is free to interpret the page as it sees fit (which it may or may not be capable of). HTML does include tags to request relative font sizes, colors, alignments and other aspects. Future versions will also include the ability to use True Type fonts and similar elements. Most browsers now handle tables and frames which have introduced a much greater control over content placement on the page. HTTP Sessions and Issues

A web server interface is effectively a GUI that is served from the device, but rendered at the client browser end. The HTTP and HTML protocols both have certain aspects that need to be understood to make full use of an HTTP system. HTTP is a client driven protocol. All actions are initiated at the client (browser) end. A client starts a session by making a TCP open to the server port (80d is the standard web server listening port). Once a connection has been accepted by the server the client issues one of the three operation commands (GET, HEAD or POST) with parameters as necessary. The server will respond with headers and body content if applicable. Once the content has been transferred, the TCP connection will be closed by the server. This is the completion of the session, as HTTP is stateless the server maintains no information across requests for different objects. HTML provides for embedded object pointers within HTML pages such as graphics, sound or video. When a client browser obtains a page from a server that contains embedded object references, the browser will perform subsequent requests to the server for each object. A separate GET request will be issued for each object. For performance reasons most browsers will open simultaneous TCP connections for multiple objects. Once all objects have been transferred to the client the browser will remain idle until the user selects a hyperlink or moves to another page. User Interface Elements Information about a device can be presented as static pages, for non changing information, or as dynamically created pages containing changing device data, graphics, text, etc. Dynamic pages are created at the time a request comes in and is built up from whatever predefined collection of elements the page requires. User interaction with the device can occur through the use of HTML forms. This is the user input method of web servers. A form is an HTML page with form elements such as Text input fields, Drop Down Lists, Radio Buttons and Check Boxes. A form page is transmitted to the browser with element definitions such as field lengths, list elements, etc. Each element has a tag name used identify it. In the beginning of the form there is also target URL that indicates where the completed form information should be Posted to. The form will contain at least one button element which, when pressed, will cause the browser to do a POST request to the URL defined in the form. The tag-name value pairs with user input will be sent along with the request. When a server receives a POST request to a URL, the URL is expected to be an application or script capable of processing the submitted data and issuing a response which the server will pass back to the client. For embedded servers appropriate data handling functions will be called, essentially the form becomes a method of setting variables on the device via the web interface. A simple form example is given below to enter a name: <html> <body> <form action="/Forms/httpcfg" method="POST"

enctype="application/x-www-form-urlencoded"> Name: <input type="text" size="20" maxlength="30" name="tel" value=""> <input type="submit" name="config" value="Submit Form </form> </form> </body> </html>

The response page generated by the form target URL can be simply the filled in form, an acknowledgement or perhaps an error message if necessary. Dynamic Data from a Server As mentioned before HTTP is client driven. One of the side effects of this is that once a page is served to the client it becomes static and does not change even if data has changed on the server side. For a user looking at a device which is dynamic, this is not very useful. There are several methods to provide dynamic like interfaces. 1. Manual refresh Refresh buttons can be placed on pages with dynamic information that the user can press to reload the page from the server with updated information. This is obviously very manual and not very appealing. 2. The REFRESH http-equiv tag Client Pull The http-equiv meta tag REFRESH can be used in page response headers to force the browser to re-request a page after a certain number of seconds defined by the variable CONTENT=X, where x is the number of seconds between refreshes. This method can be employed to periodically update the page a user is viewing by continuing to re-request and display it. The disadvantage to this method is that the entire screen will blank as the page is reloaded, since communication can be slow this is usually fairly noticeable. 3. Server Push Once a page has been loaded that contains multi-part content it is possible to maintain a connection through which the server can continue to send updated data. The data must be in the form of an image which is continuously resent by the server. This can give the affect of animation if the GIF changes just slightly each time. 4. Java and JavaScript Java will certainly increase in importance as it matures and security issues are laid to rest. The ability to upload applets to browsers that provide for more sophisticated interfaces and

higher throughput communications. Java applets and JavaScript scripts do place a burden on the embedded system code space wise. Higher end devices may be able to take advantage of this type of technology. As programmable applications Java applets can continue to request data from the device through HTTP or other connections and display the data dynamically. HTTP Security Security at the HTTP transport level is accomplished by defining security realms on a server and username\password access to each realm. When a request comes in for an object in a protected realm, the server responds with a response code of 401 (Unauthorized). This will force a browser to prompt the user for a username\password pair. The original object request will be resubmitted with the username\password, base-64 encoded, in the request header. If the server finds the login correct then it will return the requested object otherwise a 403 Forbidden response is returned. Security timeouts are implemented on the server side. The client will usually continue to submit the username\password as long as the user remains within the current realm or until the server issues another authorization challenge.

Implementing Web Servers \ Management in Devices

While the HTTP protocol is relatively straightforward, the fact that it will continue to evolve makes implementing ones own HTTP server unwise. More complex is the task of handling form Posts. Doing the parsing and data manipulation can be difficult. Since there are several vendors of embedded web servers who are continuously adding features and keeping up with the evolving web standards, there is little reason to do anything but go off the shelf. Most HTTP servers are easily integrated with TCP\IP stacks and kernels. As HTTP is a standard, the general operation of the servers will not vary too greatly. TCP While HTTP servers are not overly complicated they do have implications in an embedded system. Systems that previously were SNMP only and had IP\UDP but not the TCP transport protocol would have to be extended to include TCP. TCP is a significant addition to a network stack when compared to UDP. TCP places a burden on a systems program memory for code space, RAM space and processing time. Buffers TCP requires connection buffers, both send and receive, for each simultaneous connection. This can be several K of RAM per connection. The HTTP server itself will also need receive and send buffer space. Depending upon the exact architecture of the server the needs can vary. Do to the nature of HTML pages, responses can be fairly large and serving these responses through the buffers can require a significant amount of CPU time.

Multiple Connections Overlapped I/O on the HTTP servers can have a major effect on server performance. When a server is returning a page with multiple elements on it (text, graphics, sound, etc.) it will receive multiple connection requests from the client, one for each element. Server performance can be improved by providing multiple connections upon which data is returned, this provides the most efficient means handling the communication. This strategy requires more resources as both the number of HTTP buffers and TCP buffers need to be sufficient to handle the responses. Server Tasks The number of OS tasks that the server requires (or can use ) can have implications on both RAM use, due to the stack space per task, and CPU usage. A single task methodology for the server may require continued polling which is not very efficient for such systems. Assuming RAM is not the limiting factor, a multiple task system will probably have less overall impact on a system.

Coexisting with SNMP, Telnet and other clients When implementing a web server interface to a device in conjunction with other types of clients (to that device), it is important to establish certain consistent access scenarios. Several issues must be taken into consideration. Multiple Access If multiple access is going to be allowed to a device then some method of coordination between client sessions must done. Read type access should not be a problem except when dealing with data that could be manipulated by another client. In the case of the HTTP side it is not easy to inform a user looking at a page that the data has changed. If certain areas are protected with only single access control then at least two or more clients cannot attempt to manipulate the data at the same time. The notification problem is still an issue sine there is no asynchronous alert method in HTTP. A client would have to refresh a page or the page would have to have client-pull refresh periodically to see changes in data from another client. An SNMP agent is less susceptible to such problems. Each SNMP request is an atomic operation can show the latest data. It is up to each product as to how it wants to implement access control for multiple clients in such cases as SNMP and Telnet. Internally any multiple access capability must be managed well and data protected when needed.

HTTP Server

SNMP Agent Security \ Session Control

Telnet Server

Access Methods \ Translation

Data Data Data

Data

Session Timeouts and Priority If only a single client can be active at any one time, then sessions should be able to timeout so that other clients are able use the device after an idle client times out. The time-outs should be configurable and based on idle time. Some devices may also want to logout clients after some maximum time regardless of use. Priority schemes should be used where one client needs to be able to interrupt the other. A local console port for instance should probably always have priority access over a network client such as SNMP or HTTP. Data Access and Management Most data available through one client will be available though the others. As mentioned above some form of data protection must be done to insure consistent and up to date data is presented to the client. It is also advantageous for a system to use mostly common access methods to the data across client interfaces. This will minimize code space and increase consistency in data access. Where possible data should also be presented in similar formats so that multiple transformations are not necessary. WEB Versus Other Management Methods Due to the fact that SNMP is a well established and entrenched management protocol it is not likely to be supplanted overnight. It is important to recognize, though, that SNMP has never been the only management methodology. Combinations of Telnet, Serial and proprietary network protocols have been employed in various ways for many years. Each method has strengths and weaknesses. Serial Console Local serial console management can provide a fairly secure access method (one must have physical access to the device). Serial interfaces are cheap and easy to implement and they rely on a minimal system to be up. Serial access strength is also its weakness.

Local access means just that, local. Enterprise networks cannot be managed in this fashion. Telnet Telnet network access is usually implemented by redirecting the console through a Telnet session. The interfaces are text based and usually command prompt or menu driven. This has been the baseline remote access method for years. Any system has Telnet clients that are fairly straightforward to use. The fact that the interface exists within the device means that no external software is required to change when the device changes. Telnet is a client initiated session and therefore not capable of asynchronously sending alerts to a management station. SNMP The SNMP protocol has three elements that are key in its usefulness as a management protocol. The first is that it standardizes the access and alert methods to devices. In addition the management data is encoded in the ASN.1 standard. By standardizing these elements its possible to have third party Network Management tools that use vendor MIBs to access disparate equipment in a common way. Data can be retrieved and utilized by other applications as it is all typed and encoded in a standard fashion. Second, SNMP defines an alert message, traps, that can be directed toward one or more trap receiver stations. Traps can be collected and viewed together by a network manager and appropriate responses taken. Third, SNMP is a light protocol. It uses UDP as its transport protocol, and thus does not have connection setup and acknowledgement overhead. SNMPs disadvantages lie in part in its simplicity. SNMP V1 has little security in using plain text community names. The fact that it uses the unreliable UDP transport protocol also leaves it susceptible to lost packets. Although the fact that devices that use SNMP enable the use of standard MIB browsers these are often hard to use and not very intuitive. Most devices wishing to have better usability come with NMS snap-ins that provide a GUI. This method provides a good interface, but now the user has one more piece of software to install and maintain compatibility. The cost of SNMP is also high, both in the equipment that NMS stations are run on, the NMS packages and the cost of training NMS users. SNMP and the associated tools are an enterprise level solution not very accessible in smaller environments. HTTP\HTML (web) The HTTP protocol uses the reliable TCP transport protocol, acknowledgements and retries are therefore automatically handled. HTTP uses base-64 encoded usernames and passwords, secure sockets are also usable and MD-5 encryption\authorization will soon be used by HTTP. These schemes would make HTTP more secure than any of the other protocol methods.

Embedding a web server in a device for management and control has some major implications to both the user and the device developers. No longer does the user have to buy expensive NMS packages, the machines they run on. Since web browsers are now free with most operating systems, no special software has to be installed to manage the web enabled device. The learning curve on NMS systems and training for personnel also goes away. This can translate to substantial savings over time. Placing the interface in the device also keeps the capability self contained. Users need not be concerned with matching proprietary software revs to that of the devices. Everything is in one place. The web interfaces are also fairly simple given that the browser does the difficult task of rendering the GUI. Browser development also progresses daily providing ever more features.

The current HTTP scheme lacks two major elements; no method for asynchronous alerts and no standards for data structure or encoding such as the use of ASN.1 in SNMP. Neither of these issues would be difficult to solve as discussed in the next section. The Future of Web Management The rapid proliferation of web based management has made it clear that schemes using HTTP and standard web browsers provide benefits to both users and device developers. Several web management scheme standards are already being proposed. Sun Microsystems is pushing its JAMAPI Java Management API and Microsoft, Compaq and Intel are touting WEBUM object oriented management scheme. While these are far reaching, comprehensive projects they are not likely to move to standards any time soon. Both are complex enough that many smaller network device would be unable to implement them, that alone could prevent such proposals from gaining widespread acceptance. Several small additions to HTTP and HTML could greatly increase their ability to provide the necessary elements for management. 1. Asynchronous Alert Mechanism Implement a standard TCP listening port on web browsers capable of receiving an HTML page from network devices. Browsers and the HTML headers could use options to define browser behavior upon reception, ie. Window pop-up location, size, etc. This would enable a web browser to do both management and control as well as be an alert receiver similar to a trap receiver.

2.

Data encoding

Implement ASN.1 encoding on standard URLs to provide a consistent mechanism for MIBII like data. This would allow such systems as asset management packages to be able to collect basic information consistently. 3. Create standard management controls or browsers that all network devices could use when communicating with browsers, essentially component management systems.

Summary Web based management has a great future. There is plenty of room for extensibility and growth. Network devices can become very easy to manage thus allowing even smaller size network administrators more control over their equipment. The rapid pace of development of web tools and software fueled by Internet commerce and the consumer market will provide the management community with a wealth of cheap building blocks.