Web Based Management of Network Devices Christopher D. Leidigh American Power Conversion July, 1997

Overview Since the late 1980’s 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 HP’s 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)

MIB-II Object Tree and Groups

Tcp(6) Udp(7) Egp(8) Transmission(10) Snmp(11) Experimental(3) Private(4) enterprises(1)

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 vendor’s device MIBs would appear. This allows all MIB OID’s 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 PDU’s 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 OID’s (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 device’s 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 GUI’s 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 SNMP’s 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 vendor’s 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 (URL’s) [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: Hello World 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: Name: