Network Management Systems
Transcription
Network Management Systems
NETWORK MANAGEMENT MATTI PUSKA ESPOO-VANTAA INSTITUTE OF TECHNOLOGY 2005-2006 SYSTEMS ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Network Management Systems - Table of Contents Network Diagram Symbols iii 1 Network Management Significance and Tasks 1.1 Significance of Network Management 1.2 Network Management Functional Areas and Layers 1.3 Network Management Systems 1.4 Summary 5 5 8 11 14 2 Network Management Components 2.1 NMS Elements 2.2 NMS Protocols 2.3 Summary 16 16 17 19 3 TCP/IP Network Management 3.1 Simple Network Management Protocol Versions 20 20 3.1.1 SNMP v.1 3.1.2 SNMP v.2c 3.1.3 SNMP v.3 20 23 26 3.2 SNMP Data Model: Management Information Base 3.3 Device Management Systems 3.4 Remote Monitoring 3.4.1 System Components 3.4.2 Proactive Monitoring 3.4.3 Reactive Measurements 3.4.4 Interpreting Monitoring Results 3.5 System Management 3.6 Summary 4 OSI Network Management 4.1 Telecommunications Management Network 4.1.1 NMS Environment and Management Tasks 4.1.2 The TMN Framework 4.2 CMIS and CMIP 4.2.1 CMIS Services and CMIP Messages 4.2.2 TMN Protocol Stack 4.3 TMN Data Model 4.4 Management Systems for Telecommunication Networks 4.4.1 Public Telecommunication Networks 4.4.2 Private Corporate Networks 4.4.3 Example Products 4.5 Summary VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi 29 34 39 39 42 43 44 51 53 56 56 56 59 61 61 62 64 67 67 71 71 73 NETWORK MANAGEMENT SYSTEMS TABLE OF CONTENTS i MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 5 Distributed Management Task Force 5.1 General 5.2 Web Based Enterprise Management 5.3 Directory Enabled Network Initiative 76 76 77 81 5.3.1 DEN Motivation and Overview 5.3.2 DEN Schema 5.3.3 Directories 81 82 83 5.4 Desktop Management Initiative 5.5 Common Information Model 85 87 5.5.1 Overview 5.5.2 Classes, Properties and Methods 5.5.3 Aggregations and Associations 5.5.4 Common Models 5.5.5 Extensions 5.6 Summary 87 87 88 89 90 92 6 List of Acronyms 95 Appendices A Protocol Data Units B ASN.1 Basic Encoding Rules 100 100 104 List of References 108 VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TABLE OF CONTENTS ii MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Network Diagram Symbols Hub ATM Switch Router LAN Switch LAN Hub Uplink HLR VLR AC EIR Downlink Base Transmitter Station Base Station Controller Mobile Switching Center Operations & Maintenance Center Telephone Exhange Telephone Set Mobile System Cellular Network DB Server Workstation Ethernet Local Area Network VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi Network Management Station Hard Disk Network NETWORK MANAGEMENT SYSTEMS NETWORK DIAGRAM SYMBOLS Database User iii MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 1 Network Management Significance and Tasks This chapter covers: • Financial and technical significance of Network Management • Different Functional Areas and Functional Layers on Network Management • Device management, system management and remote monitoring 1.1 Significance of Network Management Traditionally Telecommunication Networks are run by network operators (teleoperators), that provide voice and data services to their customers. The operator builds and runs the basic network and uses the capacity for telephone, mobile and data networks and for various value added services. Customers can often buy service from many sources (Finnet, Elisa Communication, TeliaSonera, Saunalahti, Song Networks, foreign carriers...) based on the pricing, service and personal preferences. The basic network is an enourmously complex system, consisting of the infrastructure (local loops, trunks, links), transmission and switching systems. On top of the basic network the operators build and run telephone, cellular and data networks to provide sophisticated services. Computer networks used to be separate data networks. Local Area Networks connect workstations, peripherals and servers on a building, and Wide Area Networks are used to interconnect separate LANs to corporate wide intranets. The corporate intranets are often connected to the public Internet. Also computer networks are complex multivendor systems, that consist of thousands of pieces of equipment (cables, wall outlets, patch panels, Personal Computers, Network Interface Cards, switches, routers, firewalls, protocols, Client and Server software components) from tens of different manufacturers. The development points towards (data and voice) integration and (terminal) convergence. Companies use voice and data networks to achieve savings on operative costs (system administration, travelling...) and to provide better service (financial control, reachability, logistics...). Private customers use networks for personal matters and for fun (bank balances, net surfing, leasure time activities). Often the whole operation of a (large) company is dependent on the distributed EDP system. If production planning, manufacturing recepieces, logistics information, pricing, customer information, even customer service and order intake are only available on-line, the network fault means a VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 5 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY total halt of the operations. The pure labor costs of one hour downtime on a 1 000employer organisation can be estimated as follows: 1000 * 2400 • 1,4 = 19.760 Euros 170 The business losses are often higher (*. On global market service must be provided 24 hours a day. If the U.S. customer cannot get necessary product information or place an order on the Internet server at 5 p.m. local time (because of a network fault in Finland), he will take his money to the worst competitor. Odds are that he will place the tender or the order to that competitor also next time, although our server is already accepting connections. The problem may be dependent on the server, a network component or a person inside the company, on the carrier or on the Internet Service Provider (ISP). If the fault is repeatedly identified to the same partner, the company in question might consider an alternative service provider. The same applies to voice services as well. We take it for granted, that we get a good quality free line, when making a call. If the network is repeatedly busy, chances are that next time we select a different network operator or the company looks for other possibilities. Network faults can be caused by various reasons. A big source of fault is human errors (users, system administrators). Other sources include technical systems (cabling, hardware components) or software (bugs, faulty settings, incompatible software components, power feed...). Reliability can be improved with proper network design practices and fault tolerant solutions for business critical applications and systems. The reliability is measured as availability, that is the propability of the service in question being available, if needed. This can be estimated in the following way (**: MTBF Availability = MTBF + MTTR Another matter is network performance. Workstation user notices response time, i.e. the time from hitting <Enter> until he/she gets the desired service (***. Long response times might depend on several matters: PC performance, LAN loading, slow WAN links, high server loading, improper protocol parameters... *) Researches show that Fortune 1000 companies value the average cost of downtime for their ERP applications worth 10 000 - 13 000 dollars per minute, making 31 - 41 Euros an hour per employer /26/. **) 99% availability of a service is achievable with proper design, tools, attitude and good skills. Availability rates well over 99% need also fault tolerant systems. ***) Our expectations mean a lot of the experienced response times. Normally a person can wait only a few seconds without any indication or prediction of the service. On the other hand every Internet user understands, that downloading a graphical page from a foreign site tends to take a LONG time. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 6 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY On circuit switched telecommunication networks, the availability is measured in block percentage. Early network design rules stated that the daily call blocking ratio on long distance services should not exeed 1 % or 3 %, depending on the place of the trunk. Propably the current situation with several carrier providers promotes lower call blocking ratios. Network engineering tasks include end user support (helpdesk), administrative functions (system administrator) and responsibility for the health of the network infrastructure. Network Management System (NMS) is defined as a set of technical solutions, which help network engineers to improve and ensure network availability and usability, offering monitoring and configuration capabilities. Device management systems often include an early warning service, that makes it possible to start fixing the problem earlier. Maybe the fault can be found and fixed before the users notice it. Hierarchical network views and Artificial Intelligence (AI) systems help operators to locate the root cause quickly. Trouble ticket system gives some tools to analyse reliability of various network components and to keep statistics of the network availability and performance. Network load monitoring might give valuable information for capacity planning, even prevent network faults caused by excessive loading. The time to repair is the sum of the following time components (Figure 1): • Detection time, which is the time from a service fault until it is detected by the network engineers. Device or service monitoring tools often make detection time significally shorter. • Response time, the time from detection untill problem resolution is started. Often only the response time is listed in the service contract. Response time is mostly dependent on service person workload, priorities and contracts. • Repair time, which includes fault findind, correction and component replacement times. Proper fault finding tools may help making repair time shorter. • Recovery time, that is spend from fault correction until the network or the service is again on. Often this is determined by technical issues, like data recovery or Spanning-Tree recalculation. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 7 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Time to Repair Uptime Resolution time Detection Resonse Repair time time time Service on Recovery time Service off Service on Service off Figure 1: Repair time components. 1.2 Network Management Functional Areas and Layers Many problems and tasks when running a network are alike, regardles of the network type. The former CCITT (today ITU-T) has divided the tasks of a network management system into five Functional Areas, as specified in the standard X.700 and ITU-T M.3010. These are: • Fault Management, which includes proactive prevention or reactive detection, isolation and correction of abnormal behavior of the network. Fault Managements helps in problem detection, fault finding, isolation and correction. Often a device management system polls critical network nodes and fires up an alarm, when a target component continuously fails answering the polls. User interface is often based on hierarchical network maps with colour coded device symbols, to provide easy problem detection. A device management system often saves an event or a trouble ticket and can generate an automatic alarm (to a mobile phone or a pager). Trouble tickets can be used later for reliability analysis, reporting, and as input data for expert system development. • Configuration Management, which includes network (capacity) and device configuration. Configuration management keeps track of configuration data of various network components. In a simple case configuration management system displays device configuration and provides remote boot facitity. Often several configurations can be saved for a single component, and configuration files can be downloaded to the device in question, even automatically. File transfer protocols (TFTP, Trivial File Tranfer Protocol and FTAM, File Transfer and Access Method) are used for configuration file downloads. A bit more sophisticated systems include early implementations of automated configuration (DHCP, DDNS and SNMP autodiscovery). VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 8 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • Accounting Management, measuring the usage of network resources, is an important issue in telecommunication networks, but often omitted in LAN based systems. In telephone systems switches interchange counting information, the access switch of the A subscriber gathers the information and sends it periodically to the billing computer. In computer networks, accounting information can be used for network planning and fine tuning, but traffic amounts are seldom used for billing. • Performance Management ensures the network ability to satisfy the needs of multiple users. It gathers information of network loads, like WAN link capacity usage and telephone trunk utilization and displays (tabular or graphical) statistics. This information is used for capacity planning, so exactly the suitable amount of trunk capacity can be allocated. An RMON system (Remote Monitoring) provides information about the most active stations on the LAN (top talkers) that (might) need high capacity dedicated switch ports. The user is most interested in application performance, but this data is only available in certain system management tools. • Security Management includes controlling access to network resources. In the simplest form, it includes password protection and log files for the security critical network components (firewalls, routers, telephone switches) or black listing of stolen Mobile Systems on a GSM network. Some LAN equipment can generate an alarm if an unknown end system is attached, but normally this needs a single hardware vendor for active devices. Security issues on LAN environment are often dealt separately, not by network management system. As shown in Figure 2, network management tasks may also be grouped based on the view level. Different Functional Layers include the following: • Network Element Management, which is the lowest level, concentrates on hardware modules and network components. It includes device specific data only. • Network Management concentrates on physical and logical topology of the network elements, and provides a central view of all network devices. • Service Management provides information about services, that are provided to internal or external customers by the network. • Business Management offers views from the business management perspective to business processes and their availability. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 9 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Business Management Service Management Network Management Network Element Management Security Management Fault Management Configuration Management Performance Management Accounting Management Figure 2: Functional Layers and Functional Areas of Network Management. Technical NMS components are used by humans. In large organisations network administration (* is often implemented as a hierarchical model where local systems management and network problem curing are handled by local personnel. The global Network Operations Center (NOC) looks for the big picture, handles problem detection, fault finding and advices the local managers (Figure 3). The level of centralisation depends on organisation and skill of the local administrators. *) To avoid confusion, we try to use the work Network Management while referring to technical systems, while Network Administration and Network Engineers are used for human resources. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 10 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Network Management Center Figure 3: Network Operations Center 1.3 Network Management Systems As seen before, the tasks of network administration are wide. Also the emphasis depends on the implementation: when running a stable telecommunication network the emphasis is on accounting and performance, but on computer network fault and configuration management are more important issues. There is no single technical system that can handle all the aspects in different networks. Typically a network management system implementation consists of special software that is run in a multiuser platform. The management station communicates with agents on the managed devices. The spectrum of different management tools is broad, but could (perhaps) be categorised in the following way: • Device Management solutions concentrate on element and network management layers and provide status information about different hardware components on the network, their topology and status. The user interface is often based on network diagrams drawn over maps or floorplans. These systems give VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 11 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY valuable help in fault finding. Figure 4 presents a hierarchical network map for Castle Rock SNMPc, which is a good example of device managemet system. Figure 4: Castle Rock SNMPc screen. • System Management takes a system approach and is concentrated on Client/Server systems, providing service or business management views. This tool gathers a full database of IT hardware and software components. Network is often modelled as business processes, giving answers to questions like "can we perform stock inventory service now?". System management tools can also give accounting information about usage of server capacity, even network bandwidth. The user interface might take a more abstract approach. Figure 5 presents an example of the system management tools: CA Unicenter TNG Business Process View. • Monitoring tools prepare statistics about traffic details and errors in important parts of the network. The emphasize is on performance monitoring and often the information is used for capacity planning. For users, information is presented in tabular form and in graphical charts. Figure 6 presents Netscout, an example of remote monitoring tool. Monitoring tools can perhaps best be described as network management layer views. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 12 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 5: CA Unicenter TNG service management view. Figure 6: Remote Monitoring with NETscout /1/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 13 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Planning and simulating tools are used for network planning before implementation. An example is to prepare a plan of the cell structure and antennas, based on a topological model, coverage and desired capacity, on a new GSM cellular network. Documentation tools are used for preparing network documents. Besides manual inputs, they might import system management inventory database or generate simple PING-tests to discover all network nodes on a given subnet. However, they are passive tools that produce static documents and do not directly interfere with the network. Stricly speaking planning and documentation tools are not part of the network management, only the border is vague. 1.4 Summary At the end of each chapter, I will provide a summary figure about the chapter, in mind map format. My map start from the northeast corner and circles the subject counterclockwise (Figure 7). I started the chapter with a list and examples of significance of network management. Then I proceeded with the five functional areas of NMS, defined in the CCITT standard X.700: Fault, Configuration, Accounting, Performance and Security Management. The chapter ended with categories of network management systems, with screen shots of some practical software implementations. Figure 7: Summary of Chapter 1. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 14 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Review Today, networks are essential for operation of any organisation, and a network fault may prevent using distributed IT resources or handling contacts. Chapter 1 defined network management being technical solutions to improve network availability and useability. The CCITT X.700 defines five functional areas of network management: fault, configuration, accounting, performance and security management. These are common to all networks, but the importance of these areas differ from network to network. There is no single product to solve all network management needs, but often an NMS product can be positioned as a device management, a system management or a monitoring tool. Quiz You can test your knowledge by answering the following questions with a single sentence. • List the functional areas of network management, according to CCITT X.700. • How is network management defined in the course material? • How can you calculate network availability, if you know Mean Time Between Failures and Mean Time To Repair? • Estimate the cost of lost labor time for one hour network downtime for 1 000 users. • Give an example of an NMS service, which offers help to fault management. • Give an example of an NMS service, which offers help to performance management. • What is the main purpose of a device management system? • List the most important challenges for network management in computer networks. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEM MANAGEMENT SIGNIFICANCE AND TASKS 15 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 2 Network Management Components This chapter covers: • Network management elements: Manager, Agent, Protocol and Data Structure for the properties of the managed device • ISO and TCP/IP management protocols 2.1 NMS Elements (All) network management systems operate using Client/Server architecture, as shown in Figure 7. The system has the following components: • The manager is the system component which provides network engineer with information about network status, performance and events. To be able to do that, manager issues requests (based on administrator's interventions) to intelligent network devices. According to the responses, manager displays desired information on the user interface. Besides the request/response sequence, it can also receive unsolicited notifications from network devices. Normally the manager function is implemented as a special software on a powerful graphical workstation running a multitasking operating system. As the manager offers user interface, it may be regarded as a Client. • An agent is a software component on network device (Managed System). It acts on behalf of the device by receiving manager requests, getting desired information from the device and sending responses, through an abstract Managed Object interface to device hardware and software. Normally, the agent is a piece of special embedded software on a network device. Because the agent must perform additional functions and gather statistics, it consumes some additional processing power and memory. Additional end-user price of a management agent starts from about 50 Euros for bulk LAN hubs and switches. As the agent holds information, that is accessable by the manager, it is the Server component. • Manager and agents communicate either with the data carrying network (in-band management) or through a separate network (out-of-band management) using a special application protocol. On ISO (International Standardization Organisation) networks, CMIP (Common Management Information Protocol) is used, and SNMP (Simple Network Management Protocol) is the TCP/IP protocol. Both define application layer request and response types, communicating parties (who can issue the request), message formats (syntax and VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS NETWORK MANAGEMENT COMPONENTS 16 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY encoding) and the transport and network layer protocol stack needed to carry network management messages (TCP/IP or ISO). Both SNMP and CMIP use ASN.1 (Abstract Syntax Notation One) notation for message encoding. • Data Structure describes the management properties (data attributes, agent operations, behaviour of the agent and notifications) of the managed device. Both manager and agent has the same data describtion. SNMP MIBs (Management Information Base) are encoded using ASN.1. For common device categories, standard MIBs exist, which also include the possibility to expand the standard definition with the enterprise branch. Managed System Manager System GUI Manager MIB Requests Replys Protocol Operations Agent Notif’s MIB HW MO Managed Object Figure 7: Network Management Client/Server Architecture: The management system acting as a Client and the Agent as a Server. 2.2 NMS Protocols TCP/IP is the most popular protocol today. The application layer protocol for network management is SNMP, which was developed in late 80's for temporary solution for vendor independent router management. As other TCP/IP protocols, it is very simple (this is one strength of TCP/IP). Application layer protocol uses ASN.1 syntax for message and MIB encoding. For simplicity, SNMP uses unreliable UDP transport (*. On the Internet layer connectionless IP is used. SNMP/UDP/IP messages can be carried in almost any interface (LANs, circuit and packet switched networks). The TCP/IP network management protocol stack is shown in Figure 8. *) If an SNMP message is lost by the network, no retransmission is done. But the lost UDP datagram is an example of network unreliability and thus gives valuable information to the manager application. On top of this, the connectionless UDP transport is much easier (and cheaper) to implement. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS NETWORK MANAGEMENT COMPONENTS 17 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY SNMP ASN.1 UDP IP Figure 8: TCP/IP network management protocol stack. CMIP, as other ISO protocols, were meant to replace the TCP/IP solution. When the CMIP standardisation work was postphoned, equipment vendors began to support SNMP. Today, CMIP is mostly used in (complex) telecommunication networks, but quite rarely in (simpler) computer networks. It needs an ISO compliant protocol stack. Also ISO protocols can be carried in many different networks. As shown in Figure 9, in LANs, ISO IP network layer and TP 4 transport with error recovery is used. CMIP Application Presentation ISO 8823, 8825, X.226 Session ISO 8327, X.225 TP 4 Transport Network Data Link Physical X.225 ISO IP LLC1 LAPB 8802.3 V.24 V.35 V.11 X.21 8802.5 TP 0 X.25 X.25 LAPB LAPB V.24 V.35 V.11 X.21 V.24 V.35 V.11 X.21 Figure 9: OSI network management protocol stack. The third possibility is to use ISO CMIP management application protocol over a TCP/IP network. This concept is called CMOT (CMIP over TCP/IP) and was developed to make use of the popular DoD IP networks. Some LAN equipment vendors support CMOT. SNMP and CMIP protocols will be covered more detailed in chapters 3 and 4. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS NETWORK MANAGEMENT COMPONENTS 18 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 2.3 Summary Figure 10: Summary of chapter 2. Review Network management systems are based on Client/Server architecture, and consisting of a Manager (offering user interface for the network administrator), Agents (on managed network devices), a protocol (in between the Manager and the Agents) and a Management Information Base (describing the properties of the managed device). The same MIB description must reside both at the Manager and the Agent. On TCP/IP networks, application layer SNMP protocol is used. SNMP messages are transported using unreliable connectionless UDP, and UDP datagrams are carried in IP packets. CMIP is the application layer protocol for ISO, which uses the complex seven layer ISO protocol stack. Quiz • List various components of a Client/Server based Network Management System. • What is the application protocol for network management in the TCP/IP stack? • What does MIB describe? • Where does MIB reside? • What is the transport protocol used by SNMP? • Which is simpler, CMIP protocol stack or SNMP protocol stack? • List the protocols, from bottom up, on the SNMP protocol stack. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS NETWORK MANAGEMENT COMPONENTS 19 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 3 This chapter covers: • SNMP v.1, v.2c and v.3 protocols • Management Information Base definitions • Device and system management solutions • Traffic monitoring solutions • Monitoring result interpretetion TCP/IP Network Management 3.1 Simple Network Management Protocol Versions 3.1.1 SNMP v.1 Computer networks are multi-vendor systems (consisting of OSes, NOSes, protocol, networking and application software, cables, NICs, hubs, switches, bridges, routers, firewalls, modems, hosts, servers, proxies, interconnection services etc), and the management of the network devices from different manufacturers must be based on standards. The first SNMP version is a simple application standard protocol for management messages interchange, based on the former SGMP (Simple Gateway Management Protocol). Messaging is based on the Client/Server model. All messages consist of a version number, a community name and a data field (Figure 11). Version number indicates the SNMP version in use (0 for SNMP v.1). The community name is an ASCII string that realises a simple authentication (*. Both manager and agent must use the same community, otherwise the message will be discarded. The intention of the community name was to make it possible to partition the network into separate access environments (separately managed parts). The data field contains any of the five types of Protocol Data Units (PDUs). IP Packet IP header UDP Datagram UDP header SNMP Message Version Community SNMP Data GetRequest GetNextRequest SetRequest GetResponse Trap Figure 11: SNMP v.1 message format. *) In most cases, public is used for community name, at least for read-only operations. This is also the default for most systems. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 20 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY The SNMP message can also be defined using ASN.1 in this way: SNMP-Message ::= SEQUENCE { version INTEGER { version-1 (0) }, community OCTET STRING, data ANY } Compare this definition with the protocol analyser snapshot shown in Figure 12. Figure 12: SNMP v.1 GetRequest message. The manager can send the followingPDU types: • GetRequest-PDU is used by the manager to request an object value from an agent. The request contains object identifier. The community name on the SNMP message identifies the manager, and an IP number on the IP packet header identifies the target agent. Normally, the agent responses with a GetResponse message. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 21 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • GetNextRequest-PDU is used by the manager to request sequentical object information, for example for the agent to read through the rows in an interface table. The agent responses with a GetResponse message, containing the requested information. • SetRequest-PDU is used by the manager to the agent to request to set the mentionned attribute to a value specified in the request. The agent replies with a GetResponse message. As a reply, the agent sends a GetResponse-PDU, containing the requested data or acknowledment to the SetRequest. The agent can also send an unsolicited Trap-PDU to notify the manager about an unexpected circumstance, for example notifying the manager about the managed device booting. To be able to send the Trap message to a right destination, the IP address(es) of the manager(s) must be configured to the agent. The SNMP PDU types are shown in the next figure. Management Station Management application MIB Manager GetRequest GetResponse Managed device Object Object GetNextReq. GetResponse Agent UDP SetRequest UDP IP GetResponse Trap IP NIC MIB NIC Figure 13: SNMP PDU types. GetRequest-, GetNextRequest-, SetRequest- and GetResponse-PDUs (inside the SNMP header) include the following parts (see Figure 12 (*): *) The SNMP header includes version number and community string. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 22 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY (• PDU Type, indicating the SNMP message type in question) • Request ID, which is used to associate requests with the corresponding responses. With UDP, either the request or the response may get lost. • Error Status, indicating a possible error and the error type • Error Index, which associates the error with the variable in question • Variable bindings, associating each variable with its value. /3/ Format of a Trap-PDU is different from the previous, because of its function. The trap PDU indicates object type, agent address, trap type and code, time stamp and variable bindings. SNMP-message formats are defined in ASN.1, as in our previous example, and encoded using ASN.1 Basic Encoding Rules (BER). A tag, presenting the data type, and length in bytes, are added in all variables. As shown in Figure 14, BER encoding starts from the SNMP message by adding a tag and length on the message. Then various message fields (Version, Community, PDU) are processed similarly, then various fields in the PDU (Request Id, Error Status, Error Index, Variable Bindings) and finally Object Ids and values, by adding a tag and length on each field. For values, clear text numerical or ASCII coding is used, including the Community string(*. SNMP Msg SNMP Msg Tag Length SNMP Message Value Version Community Version Version Version Tag Length Value PDU Value ... Figure 14: ASN.1 BER Encoding of an SNMP Message. 3.1.2 SNMP v.2c SNMP v.2 evolved from the initial TCP/IP network management protocol version to overcome the obvious shortcomings regarding security, flexibility and scalability. The basis of the new version was Simple Management Protocol (SMP) development work, with Secure SNMP additions. The SNMP v.2 was published as an IETF Proposed standard (Internet Engineering Task Force Request for Comment) in the spring of *) Clear text coding is clearly a security risk. This issue will be addressed in the SNMPv.3. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 23 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 1993, but it never reached the Standard status. Unfortunately there arouse various security and remote configuration issues, so these were left out from the RFC 1905 SNMP v2c year 1996 document for community based version 2 protocol. SNMP v.2c supports several new data types, information modules and new message types. The version 2c PDU types are: • GetRequest-PDU, • GetNextRequest-PDU, • GetBulkRequest-PDU, that allows the manager to retrieve large blocks of data effectively • SetRequest-PDU • Response-PDU, that is equivalent to version one GetResponse, used by the Agent to answer a Get or Set message • InformRequest-PDU, that enables one manager to ask for a trap type information from another manager. This message may also be used for reliable notice by an SNMP Agent, because the receiver acknowledges it with a Resoponse-PDU. • SNMP v2Trap-PDU • Report-PDU, for reporting of an event. The name of version 1 GetResponse-PDU was changed to Response-PDU, whitch describes the role of the PDU better. Otherwise the old message types are used in the same way as in SNMP v.1 to offer backward compatibility. All messages expect the GetBulkRequest use the same PDU format, that is shown in Figure 16. Request operations may omit error status and error index. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 24 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY (* Figure 15: An example of an SNMP v.2c message and PDU . PDU Type Version Community String Request ID Error Status Error Index Variable bindings SNMP Data Figure 16: SNMP v.2 PDU format (except the GetBulkRequest-PDU). Other SNMP v.2 enhanchements include the following: • Support for distributed management strategies, by introducing the Manager-toManager MIB and the InformRequest-PDU, as introduced earlier. An SNMP v.2 system can act both as an agent and a manager. As an agent, it accepts requests from the superior manager to offer summary information. /4/ *) Although figures 11 and figure 13 refer to the same OID, the latter cannot be a reply of the former. A pure SNMP v.2c agent cannot reply on a version 1 request. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 25 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • 64-bit data type, which is useful with byte counters for high capacity interfaces. For example the value for ifInOctets for a fully loaded Full-Duplex Gigabit Ethernet interface would wrap around in 34 seconds with the previous Counter32 data type. If the value is read once a minute, the results would be meaningless. • Improved error handling by introducing new Error Status codes, and the possibility to include an exception on a Response-PDU. If multiple OID values are requested on a single GetRequest and one is not available, the agent that supports v.2c may return the values of the available OIDs and a value of noSuchObject for the errornous variable • Context, which is a collection of management information that are accessible by an SNMP entity, and a single item (=OID for an object) may exist in more than one context. An example may clarify: instead of asking a series of ifType and ifNumber requests, the manager may simply ask for ifNumber.0 value in the Ethernet context. • A new kind of SNMP Proxy, which is capable of packet forwarding (for local caching and obtaining information from a different network) and protocol translations (between SNMP v.1 and v.2c). • New version of the data model: SMI v.2 (Structure of Management Information) and User-based Security model, which will be covered later. 3.1.3 SNMP v.3 SNMP v.3, as defined in Internet Standards RFC 3410 - 3418, approved finally at the end of 2002, addresses the security issues that were postphoned from SNMPv.2. Generally speaking, there are the following four potential threads for a network management system: 1: Possibility for a third party to masquerade network management messages, and to be able to perform unauthorized management operations (like accessing or altering device configuration) 2: Possibility to modify SNMP PDU payload content, thus being able to perform a management operation that is different from the original one. The outcome would be the same as with masquerading, but an authorized message is now used as a "template". VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 26 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 3: Possibility to modify the stream of SNMP messages, for example a cracker to save a SetRequest for resetting a device and reuse that at a later time. 4: Possibility to access unauthorized information by breaking the non-disclosure relationship between the Manager and the Agent. When SNMP v.1 and v.2c messages are send in clear text, the cracker may for example access RMON packet capturing data transmitted in SNMP messages. SNMP v.3 includes authentication and privacy for secure management systems. Version 3 messages have three alternative formats. These are: • Nonsecure format (noAuthNoPriv), containing destination (twice), source and context information. This message is sent as clear text without encryption and doesn't offer privacy or authentication (Figure 17). Because it doesn't provide solution to any of the above-mentionned threads, it should't be used. • Authenticated but not private (AuthNoPriv), which adds a digest and destination and source timestamps on the message. The digest contains a checksum, calculated from the original message with one-way hashing algoritm by a secret value (Authentication passphrase) only known to the sender and the receiver. If the message is changed by a third party, the digest value doesn't match, leading discarding of the message. Any reusage trials will be detected with the timestamp. Two hasing algoritms are supported, namely MD5 (Message Digest 5) and SHA-1 (Secure Hashing Algoritm 1). This message format protects network management traffic against threads 1 - 3. • Private and authenticated (AuthPriv), which adds a digest and timestamps and encrypts the whole message (excluding the first destination field). This format offers also privacy against eavesdropping, protecting the system against all four threads mentionned above. For authentication, MD5 and SHA1 are supported, for encryption reversable 56-bit DES (Data Encryption Standard) is used. While SNMP v.3 is designed to offer extension possibilities for the security subsystem, additional stronger encryption schemes may be introduced, when needed. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 27 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY (* Figure 17: An SNMP v.3 message . SNMP v.3 includes User-based Security model and View-based Access Control Model, so certain parts of the MIB tree can be exposed only to a defined class of authenticated users /5/. As shown in Figure 18, the View-based Access Control allows or denies the access based on answers to questions who, where, how, why, what and which. From the first four, a view is formed. The object-type and object-instance are combined with the viewName for the final decision. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 28 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY who? securityModel (ver/usm/Ent) groupName securityName (user) where? contextName (deviceName/IP) securityModel (version/usm/Ent) viewName yes/ no how? securityLevel (Auth&Priv) why? what? which? viewType (read/write/notify) object-type (type) object-instance (oid) Figure 18: View-based Access Control Model. 3.2 SNMP Data Model: Management Information Base MIB describes the properties of the managed device, encoded in ASN.1. Concise MIB provides a set of macros, which are used to define SNMP v.1 management information. SNMP Agents can define a MIB, using the concise MIB, which describes the information and service they provide to the SNMP manager. The current version MIB II, RFC 1213 from 1991, was rerived from the first MIB version, while SNMPv.2 was still under development. All the MIB objects (including the MIB itself) are part of a tree, coded in ASN.1. As shown in Figure 19, the MIB tree starts from the root (.) and includes a set of branches, identified with a name and a number. A managed object parameter (presented in Figure 20 with a leave) is identified with an Object Id (OID), that is added by the Manager in the SNMP request, when requsting for a value of a given parameter. The agent decodes the OID to be able to return the value of the correct parameter. *) Compare the contents of the version field with Figures 12 and 15. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 29 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Root CCITT ISO (1) Joint ISO-CCITT Org (3) Member-body Us DoD (6) Ieee802dot11 Internet (1) Directory (1) Mgmt (2) Experimental (3) Private (4) SNMP v.2 (6) Dot11mac Mib-2 (1) System (1) Interfaces (2) AT (3) IP (4) ICMP (5) TCP (6) UDP (7) EGP (8) Host (9) Transmission (10) SNMP (11) sysDescr (1) sysObjectId (2) sysUpTime (3) sysContact (4) sysContact (4) sysName (5) sysLocation (6) sysServices (47 Figure 19: SNMP SMI (Structure of Management Information). The Object Identifier enlists branch identifiers in order. It may be presented in: • absolute textual format, starting from the root. For example, the Object Identifier of a MIB variable, describing the System Contact is { .iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 } • absolute format, starting from the root, using the numerical identifiers, like { .1.3.6.1.2.1.1.4.0 } • relative textual format, starting from a known place on the MIB tree. For example, the System Contact in MIB II is { system.sysContact.0 }. Pay attention to the fact that a relative OID doesn't have a period in the beginning. • relative format using numerical identifiers, like { 1.4.0 } • absolute or relative format, using a combination of textual and numerical identifiers, like for example { .1.3.6.1.2.1.system.sysContact.0 } Both a table entry and a single parameter value must be identified by an instance Id, that is why a trailing .0 is added in an OID for a single parameter value. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 30 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 20: Browsing the MIB tree with a MIB Browser. As shown, MIB II (.iso.org.dod.internet.mgmt.mib-2) includes the following essential(* groups, that are mandatory for a compliant implementation: • system (1) (**, including for example system description, vendor given device type, contact person, location data, system name, uptime, service count • interfaces (2), including SNMP interface numbers, interface table entries for interface type, speed, MTU (Message Transmission Unit) size, addresses, administrative and operational status, various transmit and receive counters and transmit queue status data • at (3), address translation table, mapping local physical (MAC) addresses to network (IP) addresses. This is included only for compatibility reasons. * If the protocol in question is not implemented on the managed device, the branch may be omitted **) Absolute object identifiers (starting from the root of the tree) always start with a period (.). Relative MIB specific identifiers start without the period. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 31 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • ip (4), including IP parameters, packet counters and routing and ARP table information • icmp (5), including entries for transmitted and received Internet Control and Message Protocol statistics • tcp (6), which contains transmission protocol parameters and statistics, open ports and detailed data of open connections • udp (7), containing statistical information about connectionless transmission protocol and open UDP ports • egp (8), containing EGP routing protocol message statistics and EGP neighbor table. While EGP routing is not included in all IP devices, this group may be omitted. • transmission (10), including transmission related information for 802.3, FDDI, Frame Relay, RS-232, PPP and other interfaces. • snmp (11), including a place for (future) network statistics about network management messages, PDUs and errors. Besides the listed essential MIB-II groups, there is a growing selection of standard optional groups for various purposes. Some of the most important include the following: • ospf (14), bgp (15) and rip2 (23) for other (more popular) routing protocols • rmon (16) for Remote Monitoring • dot1qBridge (17) for address table and Spanning Tree data for 802.1D bridges and switches • host (25) for host related system, storage, device, software and performance data • application (27) and dns (32) for application layer data • ifMIB (31) for detailed interface spacific data • upsMIB (33) for Uninterruptable Power Source status, battery and configurations • etherMIB (35) • atmMIB (37) for ATM (Asynchronous Transfer Mode) related interface, virtual circuit, AAL5 (ATM Adaptation Layer 5) and ATM traffic data • ipMIB (48), tcpMIB (49) and udpMIB (50) for IP, TCP and UDP compliance data and many more. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 32 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY The MIB scheme may be extended by introducing new standard objects (there is additional idenfifications available), by using the experimental group during testing and by using the private group. Private MIB extensions are stored with a vendor name under { .iso.org.dod.internet.private.enterprises }. To prevent any conflict, the vendor name must be registered by ICANN (Internet Corporation for Assigned Names and Numbers). Enclosed you'll find an example of a short-form ASN.1 definition of the uppermost layer of the Linux private MIB { .iso.org.dod.private.enterprises.ucdavis } /6/. ucdavis OBJECT IDENTIFIER ::= { enterprises 2021 } procTable OBJECT-TYPE SYNTAX SEQUENCE OF PrEntry ::= { ucdavis 2 } memory OBJECT IDENTIFIER ::= { ucdavis 4 } diskTable OBJECT-TYPE SYNTAX SEQUENCE OF DskEntry ::= { ucdavis 9 } loadTable OBJECT-TYPE SYNTAX SEQUENCE OF LaEntry ::= { ucdavis 10 } systemStats OBJECT IDENTIFIER ::= { ucdavis 11 } fileTable OBJECT-TYPE SYNTAX SEQUENCE OF FileEntry ::= { ucdavis 15 } version OBJECT IDENTIDIER ::= { ucdavis 100 } snmperrs OBJECT IDENTIFIER ::= { ucdavis 101 } mibRegistryTable OBJECT-TYPE SYNTAX SEQUENCE OF MrEntry ::= { ucdavis 102 } ucdTraps OBJECT IDENTIFIER ::= { ucdavis 251 } The manager includes the object identifier in a request and the agent returns or sets the value of this object. Normally MIB identifiers are abstracted by the network management software and a user does not have to deal with object identifiers. An NMS software often includes a MIB browser, which enables queries to MIB identifiers and entries. An example is the UNIX CMU package, which enables SNMP GetRequests, GetNextRequests, GetBulkRequests, SetRequests, Traps and MIB walking using absolute or relative MIB identifiers (see the manual pages for additional information). Enclosed are two examples of MIB walking and GetRequest (*. *) Computer printouts are shown using Courier 10 font. User input is shown in boldface. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 33 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY [matti@matti matti]$ snmpwalk -f localhost public .1.3.6.1.2.1 .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = "Linux matti.puska.fi 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586" .iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0 = OID: .iso.org.dod.intern et.private.enterprises.ucdavis.ucdSnmpAgent.linux .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 = Timeticks: (71222) 0:11:52.22 .iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 = "matti.puska@evitech.fi" .iso.org.dod.internet.mgmt.mib-2.system.sysName.0 = "matti.puska.fi" .iso.org.dod.internet.mgmt.mib-2.system.sysLocation.0 = "Veikkola Finland" .iso.org.dod.internet.mgmt.mib-2.system.sysServices.0 = 72 ... [matti@matti matti]$ snmpget -f localhost public .1.3.6.1.2.1.1.1.0 .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = "Linux matti.puska.fi 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586" 3.3 Device Management Systems In mid-size and large computer networks, an SNMP based device management system is often used. This offers status information about manageable network devices (hubs, switches, routers), network layout and traffic statistics. The network layout offers a universal view and launch pad for most network maintenance operations. The first step in device management implementation is a policy decision about network management direction (what it needed, what protocol, version, organisatio). After the policy is clear, the network infrastructure capabilities are explored and updated by purchasing only manageable devices. Modern workgroup and backbone layer 2/3 switches, MAN and WAN routers, ATM and Frame Relay switches nowadays include an SNMP agent, but for hubs (cheapest well under 50 Euros) the SNMP agent costs a lot. But hubs do not play an important role in modern LANs, so relocating them or leaving them away from the management concept doesn't make a great harm. Many operating systems (Windows XP, 200x, NT, Win 9x, UNIX, Linux...) offer a software based SNMP agent, which uses processor capacity for agent functions. According to the chosen management concept, we'll need one or more device management station (Figure 21). This is a powerful graphical workstation, running a multitasking operating system and a special software. Today, HP OpenView, Sun Microsystem SunNet Manager, Aprisma Spectrum, IBM Tivoli, CA Unicenter TNG and CiscoWorks 2000 hold the leading positions wordwide. OpenView and Unicenter have taken steps towards general purpose management platform, which includes also systems management features. SunNet Manager is clearly concentrated in device status and configuration usage (specially for Sun hosts), forming a professional tool with perhaps not so fancy graphics. Aprisma Spectrum, on the other hand, has very attractive graphical outlook and Artificial Intelligent based experts system for automating fault finding. Other products are available for small and mid size networks. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 34 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY SNMP Agent SNMP Agents SNMP Agent SNMP Agent SNMP Agent SNMP Agent SNMP SNMP Agent SNMP Agent Hub SNMP Agent Management Station Figure 21: SNMP device management system components. To offer full features, the management software also needs proprietory MIB descriptions, GUI symbols and clickable panel drawings for the managed objects. The trend has been, that the management interfaces for new devices has been first developed for the most popular management software which makes them even more popular. For device management, IP and SNMP parameters (IP address, subnet mask, default gateway, SNMP version, community name, trap destination, SNMPv.3 parameters if applicable, location and contact information, allowed management stations) must be configured to all manageable objects. If a community name other than the default public is used, the same configuration must also be made on the management station. SNMP agent configuration details depend on the implementation. Windows-hosts offer a graphical applet for agent configuration and the Linux snmpd daemon uses text files on /etc/snmp directory. General daemon configuration is done in the /etc/snmp/snmpd.conf file, including comprehensive commenting. The (short form) default access control and system contact information sections include the following: # Access Control # com2sec com2sec sec.name source localhost 127.0.0.0/8 mgmtstation 192.168.123.159/32 # group.name VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi sec.model community public public sec.name NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 35 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY #group group group group nms nms local local v1 v2c v1 v2c mgmtstation mgmtstation localhost localhost # view name all incl/excl included subtree .1 # access access group context sec.model sec.level prefix nms "" any noauth exact local "" any noauth exact mask read all all write notif none all none all # System contact information syslocation syscontact trapcommunity Veikkola Finland matti.puska@firma.fi public In cisco IOS switches and router's SNMP agent configuration are done on global configuration mode. Setting the community string enables the SNMP agent (*. If Trap messages are enabled, also the destination host must be specified. Also the sysContact and sysLocation contents can be configured: MyRouter>enable MyRouter#conf term Enter configuration commands, one per line. MyRouter(config)#snmp community public ro End with CNTL/Z. MyRouter(config)#snmp enable traps snmp MyRouter(config)#snmp host 195.148.151.107 traps public MyRouter(config)#snmp contact Matti Puska MyRouter(config)#snmp location Evitech Espoo cisco-laboratory MyRouter(config)#exit *) SNMP Write capabilities should be enabled only if absolutely necessary. In this case, I recommend to limit the SNMP management messages from a specific host/hosts, using an Access Contol List. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 36 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Because network management systems are often used in large and complex networks, the device management station discovers network nodes automatically (Autodiscovery), as shown in Figure 22. The management station first reads the local ARP table, then contacts the default gateway (hoping to get the ARP table, routing table and neighbor table, if any, from a manageable router) and finally sends ICMP Echo Requests to all local nodes. If an ARP entry is found or an Echo Reply is received, the NMS station then sends an SNMP GetRequest to discover the target SNMP status. If an SNMP Reply is received, the management station then requests for additional information about the device type, manufacturer and model, even MAC address table information. The routing table should include all (at least most) IP subnets on the Autonomous System, together with the next hop IP addresses. The remote routers are then contacted with SNMP for additional information. All manageable and nonmanageable network nodes are added to the discovery database on the NMS station. Finally, all IP nodes, device, interface and vendor types for SNMP devices, STP and IP subnet topology are discovered automatically. 192.168.123.1 195.148.158.151 GetRequest {system.sysDescr.0} GetResponse = cisco router GetRequest {at.atTable} GetResponse = 195.148.158.151 GetRequest {ip.ipRouteTable} GetResponse = 192.168.123.1 Echo Request Echo Request GetRequest {system.sysDescr.0} GetResponse = cisco router Figure 22: Autodiscovering network nodes. Based on the discovery database and address information, the management software builds network maps automatically (Automapping). Normally hierarchical maps are used (based on bridges/switches and IP subnets). With manual intervention we can manipulate the network hierarchy. Often the top-level hierarchy includes countries or places of operations and is drawn on top of a geographical map. The next level might be towns, then IP subnets, down to broadcast domains formed by switches. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 37 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Manageable objects are categorized based on device types. Important network components (like hubs, switches, routers and servers) are polled with suitable time intervals to make sure that they are operational. If a target fails to answer the GetRequest a few times successively, an event is risen. For critical components this means an alarm, leading to a visual trouble ticket and an audible sound, even a pager call. Anyway, the color of the icon of the device in question will be changed (yellow for warnings, red for alarms) and an entry to the event log will be written. Normally all instances of a device failing to reply will not cause an event (if the component is a workstation, we will not want an alarm every time a workstation user goes home after a working day!). SNMP is a poll/response system, and the polling intervals must be chosen with care. If we have 5 000 workstations and 1 000 network devices, and we configure the polling interval as 5 s for each node, this will generate: 2 • 6000 • 80 B • 8b / B = 1,54 Mbit / s 5s traffic to the segment of the management station. If 80 % of this is destined to remote LANs, we need a total of 1,2 Mbit/s capacity for SNMP polls only. On the other hand, 19,9 second interval from a fault on a backbone switch to an alarm might in some case be a long time. Also the discovery process generates some traffic and loading, so, after the initial autodiscovery, it is normally run automatically only after local business hours. The user interface, based on device symbols and network maps, not just gives information about network and device status, but also enables the manager (person) to point a device and issue data link or network layer test from a remote node to another or order a remote device to gather traffic and error statistics to be displayed on the management station. Double-clicking a node opens a device-specific management session (Telnet, WWW Browser, vendor application) to the manageable object in question. Common set of views, tools and operations may be customized as working sets. Device management systems are often concentrated in a Network Operations Center or centers and used by experts. On global organisations, the NOC must operate 24 hours a day. The centralisation also promotes the growth of the expertise needed for effective operation of network management. Device management may also be outsourced to one of the service providers offering NMS services. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 38 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 3.4 Remote Monitoring 3.4.1 System Components The SNMP request/reply protocol is unefficient in collecting information about network traffic, because the NMS station must retrieve values of necessary MIB objects at fixed time intervals. For traffic monitoring purposes, RMON MIB was developed. An RMON management station receives administrator interventions and issues commands to RMON probes. These are attached on various segments of the network, and they hear all the traffic on their segment (in promiscuous mode), collect the desired statistics and send the summary information to the management station. The RMON management station then forms graphs of the requested statistics to be displayed. RMON I is an SNMP MIB definition and SNMP protocol is used between the management station and the agent. RMON I (.iso.org.dod.internet.mgmt.mib-2.rmon) covers OSI layers 1 - 2 (Physical and Data Link). RFC 1757 defines ten RMON groups for Ethernet and Token Ring traffic. These are (Figure 23): • rmon-Traps (0) for a risingAlarm, fallingAlarm and packetMatch. Traps are sent by a RMON Probe without a request from the monitoring station. • statistics (1), including various traffic and error counters for Ethernet and Token Ring LANs (sent, dropped and broadcast frames, CRC errors, runts, giants, fragments, jabbers, collisions and frame size counters) • history (2) information about defined sample frames during a sample period for long term trending and averaging • alarm (3) information to be set by the management station to activate on special event or treshold. The agent then sends an alarm message, when the configured event occurs. • host (4) information (addresses, traffic, broadcast and error counters) • hostTopN (5), stating the top talkers and their statistics for a given period and rate base • matrix (6), offering traffic matrix about who is talking to whom (sourcedestination table) • filter (7), to filter only the interesting portion of the traffic before frame capturing or event generation. Filtering can be based on source and/or destination data link or network addresses, protocol, protocol event, elapsed time, data pattern or an error, using the bit-filter expression and mask • capture (8), to capture all or filtered frames to a frame buffer on the agent • event (9), to monitor traffic or statistical events and to send indication to the management station • tokenRing (10) specific topology, configuration and source routing information. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 39 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY RMON II offers the same information about the full OSI stack. Because it includes also the upper layers, it can provide information about end-to-end traffic, protocol and application distribution, even application usability and response times. RMON II defines additional nine new groups, namely: • protocolDir (11), including the target protocol definitions • protocolDist (12), including statistics about the target protocols • addressMap (13) of data link to network layer address mapping (including ARP tables) • nlHosts (14), including statistical information for every network address • nlMatrix (15), that holds traffic matrix for packets and errors of the network layer address pairs • alHosts (16), holding statistics and identification of the application layer addresses and names • alMatrix (17), which holds traffic matrix based on upper layer addresses • usrHistory (18) information about trending and averiging of any user definable MIB value • probeConfig (19), holding information about RMON probe capabilities, settings and functions • rmonConformance (20), including information about RMON 2 compliance and supported RMON 2 groups. Figure 23: RMON groups. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 40 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY In shared media LANs (Ethernet repeaters/hubs, Token Ring MAUs) one RMON probe is needed per collision domain. In fully switched networks, it is not possible (nor practical) to attach a probe to the ports of the switches. Fortunately most high-end switches also include a limited RMON support, so the switches (located in central parts of the network) can gather RMON statistics from the attached hosts (Figure 24). Another possibility is to use port mirroring ablility, where all the traffic of the configured port is doubled to an analysis port with the RMON probe. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 41 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Probe Probe R R Probe Probe R Probe R Port Mirroring Figure 24: Remote Monitoring system. 3.4.2 Proactive Monitoring RMON systems offer both proactive and reactive monitoring. Proactive tasks are often based on baseline measurement of a working network. Figure 25 shows an example of proactive RMON measurements. The baseline answers the question "How should our network be?". The baseline measurement should include a useful set of the following measurements from important parts of the network: • daily and weekly trends for traffic amount • traffic matrix, consisting of the top talkers and listeners • portion of broadcasts and multicast PDUs • network and application layer protocol distribution • packet size distribution. Baseline information is used for network trending, for capacity planning and directing, network tuning and as a comparision point in fault finding. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 42 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 25: Observer RMON application. 3.4.3 Reactive Measurements RMON systems also offer troubleshooting help as reactive analysis. The packet filter, capture and decode capabilities can be used for solving protocol based problems from a central place. The challenge in protocol analysis is, however, not the use of the instruments, but the need of deep protocol knowledge to make use of the vast information. Some RMON products also include packet generation and response time monitoring capabilities, as shown in Figure 26. Packet generation, however, is not part of the RMON standard. /7/ /29/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 43 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 26: Generating LAN traffic includes defining the frame, packet and segment/datagram details. 3.4.4 Interpreting Monitoring Results Total Capacity Utilization Data and voice networks are dimensioned to give good enough performance at reasonable costs. Overdimensioning brings unnecessary investment and running costs, while underdimensioning cuts some of the savings by lowering the network application performance. Especially while dimensioning WAN links, monetary costs for network connection services should be considered. During baseline measurements, capacity usage figures and time histograms for the critical network connections are ackquired. The time histogram for bandwidth utilization gives additional information, and peak-to-average ratios and peak times should be also considered. In Figure 27 we see frequent peaks at about 250 kbit/s per direction. If this is the line capacity, we have an underdimensioning, but if we pay for a 512 kbit/s Frame Relay CIR (Committed Information Rate), we should check if we really get 512 k end-to-end. Table 1 gives some guidelines when interpreting bandwidth utilization results. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 44 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Table 1: Guidelines for interpreting bandwidth utilization charts. Symptom Possible cause Possible remedy High peak rate with low average Bursty applications Control the traffic patterns to smoothen the bursts Low peak and low average, good applic. performance Overdimensioning Consider lower capacity links Frequent constant rate peaks but not on the line capacity Are you getting what you are paying for? Checking the service capacity, consider control features High average, constant peaks near the line capacity. Poor applic. performance Underdimensioning Add control features to use the capacity effectively. If this does not solve the problem, buy more capacity Figure 27: Capacity utilization graph for a Frame Relay WAN link. Often 5 minute sampling rate is used, as in this example. Bandwidth Usage Breakout The total bandwidth usage may be divided into hosts, applications and traffic classes. For capacity, QoS and performance planning bandwidth utilization per applications and per hosts gives valuable information. Concerning the application distribution, we should understand that the TCP/UDP port doesn't always indicate the correct application, as is the fact with KaZa peer-to-peer file sharing, that rides on TCP port 80, the HTTP port VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 45 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY (*. For reliable application distribution, monitoring systems that are capable of encoding application layer messages should be used. These can also identify applications that use dynamic ports, like for example RTP. When bandwidth utilization per protocol is known, network administrator can make sure, that network resources are distributed based on application needs and good enough performance is given to business critical applications. The other side of the coin is the fact that bandwidth utilization of the less important applications will be truncated. Bandwidth utilization per sender and per receiver (Top N, Host Matrix) can be used for network dimensioning and fine tuning, even for contents planning. If the biggest transmitter of bytes (Top Talker) is the intranet Web server, we may consider decoding the intranet pages using less graphics. If the biggest receiver (Top Listener) of the Internet access appears to be a music download or streaming video workstation, network administrator should have tools to correct this situation as well. Broadcast Traffic Today's network protocols and applications create broadcasts (like ARP address resolution, NetBIOS name resolution and routing updates) and multicasts (like Ghost hard drive cloning and IPTV). Layer 2 Ethernet switches don't keep an address table entry for the broadcast address, but flood the frame to all ports but the original one. Layer 3 routers forward only directed layer 3 broadcasts, but not the flooded by default. Broadcast propagation may be controlled by VLANs and layer 3 switches or routers. A thorough baseline measurement should include determining the broadcast level on critical places on the network. There is no single well-defined warning level for amount of broadcasts, but the result always depends on existing protocol, application and network environment. While the result of a broadcast on an end system is dependent on the device hardware and software, it is hard to estimate the effect on broadcast traffic on application performance. If broadcasting is suspected for performance degradation, a more detailed examination is needed. Excessive broadcasts may depend on the following problems: • Too large broadcast domain. This may be divided with VLANs, by introducing layer 3 network devices or by redesigning the network. *) This property is clearly planned to make it difficult to filter out KaZa with simple access-lists in firewalls and traffic policers. Another feature of KaZa is that is using multiple source ports for a single host, to give multiple WFQ (Weighted Fair Queuing) queues, and better performance, for a single session. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 46 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • Application operation or configuration. For example Windows hosts should not be configured as B or M Nodes, because this makes them to always use broadcasting for Windows name resolution. • Network problem, that causes excessive broadcasts. This kind of problems include Spanning Tree loops and flapping routes with an event triggered routing protocol. The cure is to eliminate the original problem or to minimise the impact. For multicasts, possible remedies include allocating the multicast application on a separate VLAN, configuring switches as multicast aware or scheduling multicast applications to low-volume periods. Ethernet Errors Distributed Network Monitoring systems or portable monitoring devices are often used for getting additional information for fault finding. RMON includes information of Ethernet errors, as well as limited statistics of other interfaces. The RMON Ethernet Statistics (.1.3.6.2.1.16.1.1) includes the following entries (see Figure 28) (*: ● Statistics Index and Data Source (ethernetStatsIndex, etherStatsDataSource), which uniquelly identify entries and the source, i.e. the interface of the data. ● Number of events of packet dropping by the probe (etherStatsDropEvents). If RMON statistics is gathered by a heavily loaded network element, some frames may be dropped due to lack of resources. Dropping lowers the reliability of the results, and should be taken into account. ● Byte counter for total volume of data (etherStatsOctets) of the selected interface. As stated by the MIB description, this gives a reasonable estimate of the Ethernet utilization. ● Total number of Ethernet frames (etherStatsPkts), including unicast, multicast and broadcast frames, as well as corrupted frames. ● Number of broadcast frames (etherStatsBroadcastPkts), excluding multicasts. ● Number of multicast frames (etherStatsMulticastPkts). *) The RMON RFC refers to packets, although layer 2 PDUs are normally called frames. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 47 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY ● Number of frames of the correct size but with an uncorrect FCS value or with an alignment error (etherStatsCRCAlignErrors). A frame with a non-integral number of bytes, like 64,5 Bytes or 516 bits, is counted as an alignment error. ● Number of frames shorter than 64 Bytes (etherStatsUndresizePkts) but with otherwise correct Ethernet format. These are sometimes called Runts. ● Number of frames longer than 1 518 Bytes, but with otherwise correct Ethernet format, sometimes called Giants. For 802.1Q tagging, the size limit is extended to 1 522 Bytes. ● Number of fragments, i.e. frames shorter than 64 Bytes with a bad FCS. These are caused by CSMA/CD collisions on a shared media network or by frame corruption due to excessive noise. ● Jabbers, i.e. too long "frames with a corrupted FCS from a single host transmitting continuously. ● The best estimate for the number of collisions, determined by the RMON probe. On 10Base2 and 10Base5 segments, an occation of two or more stations sending simultaneously is interpreted as a collision. On a 10/100BaseT twisted pair port, a collision is detected when DO and RD signals are present simultaneously. ● Number of frames of the size 64, 65 - 127, 128 - 255, 256 - 511, 512 - 1023 and 1024 - 1518 Bytes. ● Owner or the configurator of the probe, and the status of the etherStats entry. For all interfaces, Ethernet or not, OIDs on the interface branch may be used. This includes counters for input and output multicasts, broadcasts, octets and frames. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 48 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 28: RMON Statistics group. For different Ethernet errors, the following guidelines may be used, while interpreting the results: ● Collisions are part of the normal operation of CSMA/CD in shared media networks (10Base2 and 10BaseT and 100BaseT hubs). Collisions cause fragments and some runts. In a shared medium 10 Mbit/s networks, the collision rate should be kept under 10 collisions a second or under 5% in average. If the collision rate is high also during a low utilization period, a faulty Ethernet device may be the fault. Collision volume should be low on fully switched network segments. Collisions on a switched LAN may be caused by Half Duplex/Full Duplex or speed mismatches. Especially a maltfunctioning 10/100 Mbit/s speed autosensing causes 33 % or 100 % collision rate. Sometimes external noise causes errors that are interpreted as collisions. ● The most propable cause for numerous CRC (often presented as FCS error) or alignment errors on correct-sized frames is extesive noise level. This may be caused by a noisy environment, too poor noise immunity of the cable, too long cable segment or otherwise faulty cable or duplex mismatch. If you find excessive CRC or alignment errors, you should find the place and test the cable VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 49 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY segment in question. Beware of the fact that faults causing CRC errors often include phenomenons that are interpreted as late collisions as well. ● No undersized (except caused by collisions) and oversized packets should exist. If they do, the most propable cause is a faulty NIC driver, networking software or network adapter hardware. Always find the sender of these frames, perhaps with a network analysator or frame capturing, and correct the fault. Some old versions of the monitoring software may interprete 802.1Q tagged frames as baby giants, but this will be corrected by upgrading the monitoring software. ● Fragments are caused by collisions, faulty network hardware or noise. In a fully switched network no collisions should exist, but noise is more or less always present. If excessive fragments are sourced from a single host, you should test the NIC. ● On a Jabber situation a network device is sending continuously, violating Ethernet timing rules. A hub or a switch should close such a port after 20.000 50.000 bit time for awhile, and reopen it to check if the fault still exists. Jabber faults are normally caused by a faulty network adapter. Other possible sources of jabber faults include NIC driver, bad cable or groungind problems. Find the sending station and replace the NIC, so jabbers should disappear. ● Excessive broadcasts or broadcast to frame ratio indicates too large broadcast domains, poor network design or protocol misfunctioning. Broadcasts are an essential part of modern network protocols, but excessive broadcasts consume network capacity and cause unnecessary interrupts on hosts. Segmenting the network with VLANs or routers will offer means to make broadcast domains smaller. Broadcast rate should be kept under 40 broadcasts a second on a 10 Mbit/s Ethernet, but this rate should be compared to the total number of frames a second. If broadcasts are sourced from a single host, you should check the reason for broadcasts and correct any misconfigured network parameter. Performance Network usability includes both reliability and performance aspects. End-user performance could be measured by response time, i.e. time from mouse click until, but this would need measurement software on workstations. As shown in Figure 29, a normal TCP based data application traffic includes the following phases: ● TCP connection setup using the three-way handshake (SYN, SYN/ACK, ACK) for setting the initial sequence numbers. The exchange of these three TCP segments forms the connection setup time. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 50 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY ● Sending the request by the client workstation, transferring this message by the network and processing the request by the server The latter (Application Response Time) may be easily monitored by the server. ● Total data transfer time, including processing time for data frames and acknowledgement segments. For a single data/acknowledgement pair, the Round Trip Time describes the two-way network delay. ● Connection teardown with double Fin/Ack messages. This time doesnä't have affect on user response time. TCP SYN TCP SYN/ACK TCP ACK Request Time to First Byte Connection Setup Time Application Response Time Data Ack Data Connection Duration Transfer Time Data Ack Round Trip Time (RTT) FIN ACK FIN ACK t t Figure 29: TCP application traffic and some performance parameters. Because, as said, performance from the end-user perspective is hard to measure, secondary parameters are used instead. Round Trip Time may be measured either by monitoring the network traffic or by generating additional probe packets for monitoring. For server performance, local application response times may be recorded on the server. 3.5 System Management System solutions for IT, like Unicenter TNG from Computer Associates and Tivoli TME from IBM, cover network infrastructure, Windows, Win NT/2000/XP and UNIX workstations, servers, software components and service networks. For example, the user interface in Unicenter is based on application sceneries, providing information about systems serving business processes (Figure 30). Also the HP OpenView has developed a general concept in system management, covering network devices, workstations, printers, servers and client/server systems. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 51 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 30: Service view from CA Unicenter TNG system management tool. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 52 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 3.6 Summary Figure 31: Summary of the chapter 3. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 53 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Review SNMP v.1 is a simple application layer TCP/IP protocol. Version 1 PDUs include GetRequest, GetNextRequest, SetRequest (all send by the manager), GetResponse answer and unsolicited Trap by the agent. V.1 security is based only on clear text Community string. Version 2c includes some new PDUs and a concept for distributed management, but the security improvements were cancelled from this version. These were introduced in version 3, which has Nonsecure, Authenticated (digest and timestams) and Private&Authenticated (also encrypted) message formats. Version 3 also includes security and access control models. MIB describes device properties by using MIB categories for different device types and an Object Identifier tree, also including a place for private extensions. The OID is present in every SNMP request and response and it uniquely describes the parameter in question. SNMP based device management systems offer status information about manageable devices, network layout and traffic statistics, and include autodiscovery, status polling and parameter retrieval. An RMON monitoring system includes RMON probes, collecting data and sending summaries, and an RMON station which issues commands and displays monitoring information. The RMON system can be used for proactive (baseline) and reactive (troubleshooting) tasks. System Management tools offer a common view of the whole IT infrastructure, maybe based on business processes. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 54 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Quiz • In SNMP v.1, what is the response to a SetRequest PDU? • In SNMP, what is the purpose of MIB? • List the five different SNMP v.1 PDU types. • What is the SNMP v.1 PDU type that an agent can send without a request from manager? • What are the most important shortcomings of SNMP v.1 which were corrected by version 2c? • What is the purpose of Community name in SNMP v.1 and v.2c? • List the three different message formats of SNMP v.3 • What is the purpose of OID? • How can vendor specific data be presented in SNMP Structure of Management Information? • Give a few examples of data in the .iso.org.dod.internet.mgmt.mib2.system branch of SMI. • What parameters must be configured on an SNMP agent? • What is Autodiscovery in the NMS context? • What is polling in the NMS context? • What factors should be considered when choosing polling interval for a device? • Give an example of information provided by an RMON system. • What is the function of an RMON probe? • What is the main difference between RMON and RMON II? • Give an example of proactive RMON measurement. • Give an example of reactive RMON measurement. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS TCP/IP NETWORK MANAGEMENT 55 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 4 ISO Network Management This chapter includes: • Telecommunication Management Network framework and management tasks • Common Management Information Services and Protocol • Object oriented TMN information model • Example Network Management System implementations 4.1 Telecommunications Management Network 4.1.1 NMS Environment and Management Tasks Public telecommunication services have been regulated by local laws and authorities. Public networking services have evolved from fixed telephone networks, run by local telephone operators which had national or local monopoly and offered services defined by the operator to all customers at the same tariffs. Besides the passive local loops and trunk cables, the network elemens consist(ed) of access devices, local exchanges, hierarchical switching components and transmission systems, based on international standards and supplied by different vendors. Network of the local teleoperators were connected together by national and international switches. Today, telecommunication networks are mainly digital, sometimes even down to the customer premises equipment. Running and planning a stable (monopolistic) circuit switched telephone network used to be a quite straight-forward task. Today the basic network is also used to carry data, mobile communications and voice from value added services. New services (data, mobile communication, the Internet, value added services) have grown very rapidly (in industrial countries), making the trend based capacity planning useless. Also the nature of the traffic is changing from constant bit rate to variable bit rate and bursty (the traffic profile of LAN interconnections, the Internet access, video conferencing, MMS and GPRS data is far from constant). The Open Network Provisioning by the European Union opened telecommunication markets to national and international competition in 1995. An operator (excluding some minor EU member countries, which have an adaptation period) must lease trunk and access capacity to all service providers at a reasonable price. Even a more radical deregulation development took place in the USA, where the new Telecommunications Act in 1996 opened the US communication markets, including local, long distance and international calls, Internet, data and value added services to various parties like Local Exhange Carriers, Inter Exhange Carriers, Cable TV companies, broadcasting VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 56 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY companies and Interner Service Providers (*. Competitors have developed a wide variety of new services. One of the outcomings of the international deregulation is series of merges, acquisitions and alliances. The technical aspect of the business development is first, that new service providers (** use leased capacity (and network elements) from various Local and Inter Exchange Carriers (formely managed by the owner), combined with the central switches and billing systems run by the service provider itself. Second, the merges rise problems to integrate network management systems from different companies, developed separately. Third, heavy competition promotes costeffectiveness (taking advantadge of all the technical aids available), customer satisfaction (based also on the technical quality of the service) and rapid development of new services (needing new kinds of management information). Network Management Systems for telecommunication networks can be divided into the following categories (see Figure 30): • Basic Customer Support systems provide monthly report generation and Service Desk systems, receiving toll free calls from existing customers for service orders and changes. • Element Management Systems (EMSes) manage individual devices. These include management of basic access devices, switching and transmission systems and service specific EMSes, for example for Intelligent Networks (like x700/x800 services), leased data lines and Virtual Private Networks (VPNs). An EMS typically offers fault management, trouble ticketing system, performance statistics and problem resolution aids and provides mainly element layer views. Often an Element Management System is vendor specific, relative inexpensive solution which only needs a part time operator. • Integrated Network Management System (INMS) integrates different vendor specific EMSes into a single management interface. An EMS outputs its information, which is received and handled by the INMS and coordinated with data from other EMSes. The INMS also offers a standards based protocol interface, at least upstream. An INMS provides mainly network layer views. *) US Regional Bell Operating Companies are not allowed to offer inter LATA services until they open their Local Access Transport Area for competition. **) The old national monopolies tended to favour the local telecommunications industry (Siemens in Germany, Alcatel in France...). New voice, mobile and value added operators do not have the historical burden, instead they often tend to choose a supplier that is different from the worst national competitor. This has opened much business opportunities to new (Finnish!) manufacturers like Nokia and Tellabs. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 57 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • Multi vendor Ingegrated Network Management System is the manager of the management systems, providing a single user interface and console for network wide control and observation tasks. A multi vendor IMNS is an expensive system (of the range of hundreds of thousands of Euros) which is normally situated in the Network Control Center and operated by the specialists 24 hours a day, 7 days a week. The system offers the big picture: status information and statistics of the whole network and all services. • Operations Support System (OSS) integrates network management with business processes. Typically, the OSS system includes software tools for sales, marketing, provisioning, product development and billing. High-quality support systems make it possible to differentiate and customize services according to the customer needs, although services are based on the same network infrastructure. An OSS provides service and business management views to the network. User Interface OSS Integrated Network Management System DB Element Management System Managed Objects Transm. system Figure 30: Network management hierarchy in telecommunication networks. Users of a public telecommunication network do not accept breaks. To provide full time usability, redundant network design is used. Redundancy makes the network more complex, and it is harder to get the full picture at a glance. Private corporate telecommunication networks (consisting of Private area Branch Exhanges, multiplexers and leased line trunks) are often more tolerant of faults, because the public telephone network can often be used as a backup. Concerning the corporate networks, the problem VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 58 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY is to what extend the components of the public network should be included into the private management concept. Seconds Milliseconds Microseconds Load Bal. & Distr. Minutes Parameter tuning Hours Billing Days Design Weeks Problem Determination Trends Analysis Years Capacity Planning Figure 31 presents some of the times required to accoplish a selected network management task /9/. Services like trend analysis and capacity planning do not require fast observations and responses, so they are best done with network management systems. On the other hand, load balancing and distribution, as well as parameter tuning require a second or faster response times. Broadband technologies like ATM and SDH offer a rich set of functional and performance monitoring information, but the NMS system must select only the relevant data for observation. Trivial routing, rerouting and parameter tunig tasks are often done at the component level without NMS intervention. Figure 31: Examples of service times requirements of some NMS services. 4.1.2 The TMN framework Telecommunications Management Network is an ITU standard (ITU-T M.3010 in 1992), including ISO management components, and service and protocol specifications for telecommunication networks. The functional areas for TMN management are the same as presented previously (see chapter 1.2). The framework is based on the management/agent concept, including the following building blocks (see Figure 32): • Network Elements (NE) offer data carrying capacity and present management needs. The network of NEs provides circuit and packet switching services for user data. • Data Communication Network (DCN) is a separate packet switching network for NMS messages. It supports the ISO protocol stack and the application protocols used in TMN. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 59 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • TMN manageable NEs are connected directly to the data communication network through a Q interface. A Q adapter (QA) is used to connect older network elements which do not directly support TMN. • Network management tasks are carried out by an Operations System (OS), which normally is a combination of hardware and software. It offers fault, configuration, accounting, performance and security management services. • Network managers use the OS functions through a workstation (WS), which offers the necessary user interface for network configuration, alarm logging etc. • Mediation Device (MD, not shown in the figure) performs protocol conversion between different management systems connected on the same DCN. Telecommunications Management Network Operations Systems Qx Workstation Data Communication Network F X Qx Qx Q3 Qx QA Q Adapter M Transm. system Q3 QA M Transm. system Network Elements in the Telecommunication network Figure 32: Telecommunications Management Network architecture. The TMN architecture also defines the following interfaces: • Q3 interface is a full OSI layer 1 - 7 interface between the DCN and the management elements • Qx interface is an interface between a TMN element and the Data Communication Network, which doesn't provide a full OSI layer 7 TMN protocol support. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 60 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • F interface is the interface to a management workstation (which provides user interface) • X interface is the interface between two TMN systems • M interface (actually outside the TMN scope) lies between a Q Adapter and the non-TMN device. Management services are defined in Common Management Information Services and operations for network elements are send with Common Management Information Protocol messages. These are covered in more detailed in the next chapter. /10/ 4.2 CMIS and CMIP 4.2.1 CMIS Services and CMIP Messages CMIS is a set of standard management services. It specifies types of requests, responses and notificiations and what they can do. CMIP is the management protocol, which defines how requests, responses and notifications are encoded, and operations which are used to transport messages. A CMIP message usually specifies the target managed object. CMIS services are encoded using ASN.1. CMIS specifies the following services. All services support confirmed request operations, which always requires a response (either a positive or a negative). Some operations also support unconfirmed operations where a response is not expected. The services specified by CMIS are: • M-Get service, used by a manager to request for information from an agent. This service uses M-Get Request and M-Get Response primitives which are mapped into CMIP messages (m-Get request PDU, m-Linked-Reply response PDU and mGet response PDU). Messages caused by an M-Get service are always confirmed. • M-Cancel-Get is used by the manager for cancellation of a previously assigned request. Primitives are, accordingly, M-Cancel-Get Request and M-Cancel-Get Response. Also M-Cancel-Get service uses only confirmed operations. • M-Create, used by a manager for an object creation by an agent. Also the creation service is always confirmed. • M-Delete is used by a manager for one or multiple object deletion by an agent. This service is always confirmed. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 61 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • M-Set, which is used by the manager for an agent to set an attribute value of a managed object to a specified value. This service can use confirmed or unconfirmed operations. • M-Action, used by a manager to request, that an agent invokes a specified behavior supported by a managed object. This service can use both confirmed and unconfirmed operations. • M-Event-Report is issued by an agent to send a notification information to a manager. These operations can be confirmed or unconfirmed. The agent uses MEvent-Report Request primitive and m-Event-Report request PDU or m-EventReport-Confirmed request PDU. In the latter case, the manager confirms the event report with a m-Event-Report response PDU. Manager and agent implementations are not required to support all CMIS defined services. When an ISO manager and an ISO agent first establish communication, they agree on the types of services (Functional Units) which can be used by them. Functional Units include multipleObjectSelection, multipleReply, filter, kernel, confirmedCancelGet and extendedService. The first two are used for scoping, i.e. directing a single request to several managed objects. Before carrying the request, the agent can use filtering to make sure that the request is intended to this specific agent. The kernel unit defines a minimum set of services every ISO manager or agent must support. 4.2.2 TMN Protocol Stack As shown in Figure 33, the full Q3 protocol stack, used in TMN systems, includes the following protocols from up to down: • CMISE (Common Management Information Service Element) Application part, that provides TMN services • CMIP, that forms the application layer PDUs • ROSE (Remote Operations Service Element) for application layer PDU delivery and ACSE (Access Control Service Element) for application-to-application communication • ASN.1 encoding on the Presentation Layer • X.225 on the Session Layer • connection oriented ISO TP4 (Transport Protocol 4), also called Connection Oriented Transport Protocol (COTP), or sometimes TP0 aka ConnectionlessMode Transport Protocol (CLTP) on OSI Layer 4 • ISO IP (Connectionless-Mode Network Protocol, CLNP) on the Network Layer VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 62 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • any Layer 2 and Layer 1 interface, for example connectionless LLC Type 1 and CSMA/CD on 802.3 LANs. ------------ MAC Header -----------MAC: Destination: 00-E0-29-15-67-D9 MAC: Source: 00-40-43-F7-D8-EA MAC: Length: 101 MAC: FCS: 065FB4CD ------------ LLC Header -----------LLC: Dsap: 0xfe (254) LLC: Ssap: 0xfe (254) Command LLC: Unnumbered frame: UI (3) ------------ CLNP Header -----------CLNP: Protocol Identifier = Full ISO8473 CLNP (0x81) ... CLNP: Src Address length = 20 CLNP: Src Address format = ISO DCC (Binary) (0x39) CLNP: Src Address = 0x246F00000116000000010001123456789ABC00 CLNP: Data Unit Identifier = 26100 CLNP: Segment Offset = 0 CLNP: Total Length = 98 ------------ COTP Header -----------COTP: Length Indicator = 4 COTP: TPDU code = Data (0xF0) COTP: DST-REF = 0efb COTP: EOT = 1 COTP: TPDU-NR = 123 ------------ SESS Header -----------SESS: SI = Give Tokens (1) SESS: SI = Data Xfer (1) SESS: User Data Length = 32 ------------ PRES Header -----------PRES: PDV List [0] PRES: Context Identifier = 3 PRES: Single-ASN.1-Type ------------ ROSE Header ROSE: rors-apdu ROSE: invokeID = 308 ROSE: operation-value = 3 ------------ ------------ CMIP Header CMIP: Result = M-Get (3) Figure 33: Q3 Protocol Stack. ------------ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 63 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 4.3 TMN Data Model TMN specifies also an object oriented data model. The object oriented paradigm provides more flexible, more intelligent and simpler modelling for complex objects than tree structured OID tree used in SNMP. The TMN data model includes the following concepts: • A managed resource is a network device or a logical unit. We can think that a managed resource is a real physical or logical device or piece of a device on the managed network. • A managed object class specifies the structure and behavior of a managed resource. A class includes a name, attributes, behaviours, actions and notifications. An attribute value may be read by M-Get and set by M-Set, an action may be invoked by M-Action and the agent may send a notification by MEvent-Report service. Behaviours present the internal device operations, that are directly invisible to the network managemen system. • Inheritance is the relationship between the managed object classes. When a derived class can inherit properties (attributes, behaviours, actions and notifications) from its base class, inheritance forms a powerful means to define class properties. • A managed object or object instance is a view of a managed resource, which presents the information needed to manage the resource. When we create an icon for a managed resource on an NMS station, we create a named instance for a given managed object class. • Containment is a relationship between managed object instances. Containments may present real world dependencies. The CCITT X.721 Definition of Management Information (DMI) defines several managed object classes, name bindings and support constructs. These classes are base classes to be used for defining other classes. All start from the top which is the base class for all other object classes. Top cannot be instantiated directly, but, for inheritance, the objectClass and nameBindig attributes defined in top are supported by all classes. All other classes are subclasses of the top. The Object Class Inheritance Tree represents the inheritance relationships between managed object classes. The inheritance tree for the managed object classes defined in the DMI is shown in Figure 34. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 64 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY top discriminator log logRecord eventForwardingDiscriminator system eventLogRecord alarmRecord attributeValueChangeRecord relationshipChangeRecord objectCreation- objectDeletionRecord Record securityAlarmReportRecord stateChangeRecord Figure 34: Object Class Inheritance Tree for DMI defined managed object classes. The Object Identifier Tree contains node labels, using nonnegative integer values and text labels. For example, the Object Identifier of the alarmRecord is: { top logRecord eventLogRecord alarmRecord } The GDMO (Guidelines for the Definition of Managed Objects) guidelines provide templates for defining managed object classes. The classes allow agents to describe what information and services they provide and GDMO defines the format for this information. For each managed object class, the following information is defined: • attributes (types of data) supported by the (managed object) class • operations (actions) supported by the class • the behavior of the managed object • notifications (types of unsolicited information) a managed object can send to a manager. GDMO follows the object oriented model. It includes two basic templates: the MANAGED OBJECT CLASS (* and NAME BINDING, which are always implemented. GDMO also defines several optional templates which may be referred by the basic templates.The minimum MANAGED OBJECT CLASS template for our example class is the following: Router MANAGED OBJECT CLASS REGISTERED AS { top system router } VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 65 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY GDMO definitions are recommended to be presented using UML (Unified Modeling Language). The Class Diagram (Figure 35) presents the static structure of the system, while the Object Diagram describes instances and their relationship. Figure 36 includes an example of object diagram. /27/ /28/ Router hostname includes 1 defined_by model 1 Chassis chassisId state 1...* * Psu psuSerial state temp * ifType state inherits * 1...* 1...* CpuCard MemCard processor clockRate load * EthCard AtmCard SerCard slotId speed hd 1...* includes ram rom flash defined_by Config runConfig startConfig show() copy() erase() slotId slotId aalType clockRate qosParams encapsul 1...* Sw curConfig 1...* IfCard 1 defined_by Hw 1...* Ios version size show() copy() includes 1...* Interface Interface Interface intId outOctets intId outOctets intId outOctets shutdown() shutdown() shutdown() Figure 35: UML Class Diagram presents class inheritange and associations. Relationship between managed object classes and managed objects of the same and different classes is called a containment, and it is defined by Management Information Tree. The containment relationship is between the object instances, not classes, and is capable of reflecting the real world hierarchy between resources. For example, a router hardware contains chassis, a PSU, a CPU card, a memory card and two interface cards, each of the latter containing two interfaces. The containment relationship can also reflect the behaviour of the device, so when the router is off, we cannot access an interface on an interface card in the router. In the ISO management, the containment is not restricted to reflect physical containment of the managed resources. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 66 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY The containment relationship is used for naming managed object instances. A subordinate object instance is named by an unambiguous combination of: • the name of its superior object • a pair of an identifier and a value of one of the subordinate object attributes (the naming attribute). Following the hierarchy, the superior object instance is named relative to its superior. This hierarchy is called the Management Information Tree (MIT). Figure 36 shows an example of a MIT. The figure also shows an example of an object instance name (Distinguished name) { hostname=Evitech123. model=4006. ifType=eth. slotId=1. intId=1/0 } /10/ /27/ hostname: Evitech123 model: 4006 :1234567 :24680 intId:1/0 ifType: eth :ser slotId:1 :2 :1/1 :2/0 :290702 :68030 :16777216 :290702 :V12R06 :2/1 Attribute Value=1/0 Attribute Identifier=intId Object DN={hostname=Evitech123.model=4006.ifType=eth.slotId=1.intId=1/0} Figure 36: A Management Information Tree example. 4.4 Management Systems for Telecommunication Networks 4.4.1 Public Telecommunication Networks Element Management Systems by different equipment manufacturers offer fault, performance, configuration, accounting and security management functions for mobile networks, transmission and switching systems and broadband networks. Often all management functions and applications for a network are integrated into a single system, as shown in Figure 36. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 67 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY DB Import Export CDB access Central DB SNMP Proxy PaBX If. Management Application Platform Fault Perf. Conf. Acc. Phone Mgmt Mgmt Mgmt Mgmt Dir. etc. Security Management Figure 36: Element management platform for PaBX's. /12/ As device management systems for LANs, also the Element Management systems provide autodiscovery, device inventory, cental database and hierarchical network maps, down to the module level. Simple element managers might use an (effective!) character oriented user interface, but more sophisticated systems use graphical icons and provide the command shell only for device configuration. Separate Element Management systems can be integrated with an umbrella management system (Manager of Managers). This means that the element management systems provide a standard based interface for the higher layer management. It receives and evaluates alarm reports generated by the EMSes, performs status overview of the entire public telephone network, and provides management functionality for simple agent based network components (Figure 37). Also private packet switched data networks are often integrated under the common umbrella. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 68 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Umbrella manager function Mux Host mgmt mgmt function function Proxy Agent P r o x y A g e n t s Mgmt for mobile systems Uplink HLR VLR AC ATM manager PaBX nw manager Data network manager EIR mux Downlink Base Transmitter Station SNMP Agents Base Station Controller Mobile Switching Center Operations & Maintenance Center Mobile Systems ATM PaBXs Mux and Hosts Private Telecommunication Network Private Data Networks Figure 37: Manager for the Managers. Networks managed by the Element Management and umbrella management systems are used to offer, provide and invoice services. An Operations Support System (OSS) widens the perspective of network management from technical aspects to business processes. The OSS provides software tools for the following tasks: • customer acquisition: information services for preparing offers and selling existing and new services to existing and new customers. OSS services in this field provide, for example, rough and detailed implementation plans for customer specific services, including trunk and equipment capacity, realistic time table and cost analysis. • order management for order input and tracking, and project management tools. The OSS interpretes customer orders into electonic work orders, and also links data from and into project with labour cost bookkeeping. • product development and service provisioning for designing new services, including cost analysis and simulation. • inventory management, providing usage, service history and reliability information. The equipment inventory database is used for most of the above mentionned tasks. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 69 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • network management, providing views of network operation and performance, from the customer/service perspective. The data originated from the technical NMS system is further processed to provide business oriented information. • trouble management, providing network surveillance, alarm handling and trouble ticket processing. Again, technical NMS data is projected into service and customer specific information. • billing and customer care, to automatically generate periodic bills and reports to the customer. Reports include statistics about network usage, availability and other quality parameters. The data is also used for bookkeeping and further processed into managerial reports, from account manager up to the CEO level. • automated business processes, that synchronize all of the above, using an electronic workflow management system. Technically, the OSS operating environment is a heterogenous multi-platform multivendor system, including network elements, NMS systems and financial systems. The user base is not only technical experts, but also sales persons, department managers, directors, and also people from the customer and partner organisations. From the business perspective, a state of the art OSS systems can help the operator to success in the international competition, to cut down operational costs, to develop and implement new customer oriented services and to offer premium customer satisfaction. Today's deregulation and competitive environment sets up need for flexibility and customer awareness of teleoperators. For service providers, this leads in seeking new ways to differentiate service offerings, introducing new services rapidly and becoming service oriented (providing different service level agreements instead of bulk capacity leasing), and reducing operating costs (also for network management) at the same time. One technical trend is the transition from circuit switched networks to packet switched IP networks (Voice over IP, secure Virtual Private Networks, 3G mobile networks), which offer a quaranteed (even differentiated) quality or service. From the technical point of view, telecommunication networks become closer to computer networks and TCP/IP LANs and intranets. Based on the IP network infrastructure, the service provider will offer different services (like VPNs, eCommerce, cost-effective Internet telephony, Internet Access, broadband services...) for different customers. This certainly brings new demands for the network management: the NMS system must offer real time service oriented data from new types of network devices. /12/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 70 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 4.4.2 Private Corporate Networks Medium- and large-sized companies have built their own PaBX networks, often using leased lines or own fiber capacity (power, broadcasting and railroad companies). Switching, transmission and multiplexing systems have been managed by system specific element management systems. Often LANs are interconnected into corporate intranets, allocating a part of the trunk capacity for data and managed by an SNMP device management systems. Some larger companies have also put up higher layer Integrated Network Management Systems. The same trends of integration and mobility also apply to corporate networks. Some companies have decided to oursource their data and voice networks and the network management and use value added services and the expertese from the selected service provider. Some companies decided to run and develop their own network themselves, and clearly they also need sophisticated network management systems. 4.4.3 Example Products Our first example of network management software for telecommunication networks is Nokia NMS/2000 which is the management solution for network elements and systems of cellular networks made by Nokia. As shown in Figure 38, the NMS/2000 is a Client/Server system. Communication servers are gateways between the managed objects and the management system, database servers store information about the managed network elements and application servers run the terminal sessions for the clients. Operators are sitting by a UNIX or a PC workstations or an X Terminal, and run an X terminal session on the application server. The server components can be combined for simplicity and dublicated for redundancy. The management elements are connected together with a shared media or switched Ethernet LAN, using the TCP/IP protocol stack. The managed objects are accessed through a DCN network, using either TCP/IP or ISO protocols. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 71 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Base Station Controller Database Server Application Server Communication Server DB HLR VLR AC Base Transmitter Station EIR Mobile Switching Center X.25 or LAN: TCP/IP or ISO LAN: TCP/IP PC workstations X Terminals UNIX-workstations Figure 35: Elements of a Nokia NMS/2000 network management system. The NMS/2000 system provides the following management applications: • An NMS Desktop, which is a collection of applications for viewing, locating and handling managed objects and starting applications. • Fault Management includes graphical tools for viewing active alarms and an alarm manual and for searching the alarm database. • With Performance Management, the cellular network can be monitored and reported. Continuous monitoring looks at the quality of service of the network and periodical reporting provides information for network planning, optimising and dimensioning. • Radio Network Management includes tools for integrating sites, modifying the network configuration and setting the radio network parameters. • Configuration Management includes applications for hardware and software configuration. • System Management includes tools for system administration tasks, like user management, user profile configuration, granting specified management authorities for managers and checking the status of the management database. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 72 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • For a specific task, the operator can initiate a remote MML Session (ManMachine Language) to any network element. The vendor specific MML command language is often the most effective user interface for an experienced operator. 4.5 Summary Figure 39: Summary of chapter 4. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 73 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Review CMIP is a complex NMS protocol which is used in large and complex telecommunication networks. Competition situation, service differentiation and merges require technical means to gain customer satisfaction. Different categories of telecommunication NMS include vendor specific enterprise NMS, integrated NMS with standard interfaces, multi-vendor INMS, which consolidate NMS systems to a single user interface and Operations Support System, which integrate NMS with business applications. The Telecommunication Management Network framework includes manageable network elemets for user data, packet switched Data Communication Network, Operations System, workstations and standard interfaces between building blocks. The TMN data model is an object oriented model to describe managed devices, including classes with inheritange and managed object instances with containment relationship. The GDMO guidelines provide MANAGED OBJECT CLASS AND NAME BINDINGS templates for defining managed object classes, and Management Information Tree defines the hierarchy between superior and subordinate object instances. CMIS defines a set of standard management services, while CMIP is the management protocol, defining messages, message encoding and operations to transport messages. Element Management Systems, often vendor specific, provide a subset of fault, performance, configuring, accounting and security management functions for telecommunication networks. Separate Element Management Systems are integrated with a standards based Integrated Network Management System. Operations Support Systems integrate the technical NMS with business applications. OSS tools may include tools for customer acquisition, order management, service development and provisioning, billing and reporting and trouble management. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 74 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Quiz • What common trend for telecommunication service market in Western Europe and in Northern America took place in 1990s? • What is the purpose of Integrated Network Management System? • What is the purpose of Operations Support System? • In what kind of networks is the OSI NMS protocols normally used? • Give an example of a service provided by OSS. • Sketch a figure, showing relationship between various TMN (Telecommunication Management Network) architecture components: DCN (Data Communication Network), NEs (Network Elements), OS (Operations System), QA (Q Adapter), WS (Workstation) • What is the difference between the NE network and the DCN? • Is the TMN data model object oriented? • What is the difference between CMIP and CMIS? • What is the purpose of GDMO (Guidelines for the Definion of Managed Objects)? • What functions does an Element Management System offer? VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ISO NETWORK MANAGEMENT 75 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 5 Distributed Management Task Force This chapter includes: • DMTF organisation and initiatives • Web Based Enterprise Management • Directory Enabled Network • Desktop Management Initiative • CIM information model 5.1 General DMTF (Distributed Management Task Force) is an industry organisation for promoting management standards for desktop, enterprise and Internet environments. It was founded in 1992 by 3Com, Cisco, Hewlett-Packard, Microsoft, Sun and others, and at the time of writing (6.5.2003) includes more than 150 companies and public organisations. As other vendor forums, also DMTF promotes its goals by guiding and coordinating standards development and ensuring compatibility between implementations. DMTF works with close co-operation with IETF and other standardisation bodies, IETF concentrating on protocol issues and DMTF on integration of the management environment. DMTF initiatives, standards and technologies form an architecture to enable business operations and reduce IT operational consts. The DMTF initiatives include the following: • CIM (Common Information Model), an object oriented general and implementation-neutral information model for management information. • DMI (Desktop Management Initiative), including a framework for mobile, desktop and server computer management and tracking. • WBEM (Web Based Enterprise Management), standards for unifying network management of enterprise IT environment. • DEN (Directory Enabled Network), mapping CIM concepts to a directory and integrating management information with other WBEM elements. • SMBIOS (System Management BIOS), including BIOS extensions for Intel based computers to provide low-level hardware information. • ASF (Alert Standard Format), a system for collecting and sending system health information during low-power and OS-absent states. ASF also accepts commands, like remote power up, power down and reboot. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 76 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY DMTF standards are widely approved and implemented by the industry. Examples of DMTF technologies include CIM and WBEM in CiscoWorks2000, HP OpenView and Oracle system management for integration with other management tools, DMI interfaces for desktop management in Dell, HP and other leading PC vendors, Windows Managemen Instrumentation (WMI) management interface and tools, based on CIM, by Microsoft, and ZENworks by Novell, based on DMTF technologies like DMI, CIM, SMBIOS and many others. /31/ /32/ 5.2 Web Based Enterprise Management WBEM (Web Based Enterprise Management) is a set of network management technologies, which are developed to provide a unified method for NMS in large complex enterprise networks. WBEM was published in 1999 by Interop Workgroup. Although based on Client/Server model, WBEM realises the fact that modern network components have a lot more processing power, more detailed information of their status and better resources to take an active role on network management as a single NMS station. As shown in Figure 40, WBEM includes the following system components: • CIM NMS support in managed network devices (CIM Servers). The server receives and processes CIM requests and returns response messages. It consists of CIM Object Manager (CIMOM), responsible of communication with other CIM system components, Providers, which instrument the CIM Schema and provide interface to the real world network component, and CIM information model. • CIM Client, which issues CIM requests to servers and receives responses. The client provides the User Interface for network engineers. • HTTP protocol between the Client and the Server. CIM Operations over HTTP defines a protocol independent way to transport XML/CIM messages inside HTTP PDUs and perform CIM operations. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 77 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Managed Network Elements CIM Server CIM CIM Server Providers CIMOM CIM Providers CIMOM CIM Ops over HTTP Network Engineer CIM Client Figure 40: WBEM Client/Server system. Practical WBEM implementations offer tools for management of a complete network, consisting of different devices from different manufacturers. The user (=network engineer) uses a Web browser to communicate with the manager system. The manager system collects data from managed devices, using the standards based CIM or SNMP protocols. The data is analyzed to produce network maps and statistical graphs. Network element and configuration data is stored in a central database. The user issues HTML requests to the Web server that requests data from the management database with user information for data security (see Figure 41). VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 78 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Manager System Web Server Manager Information Reposity DB Configurator Collector Analyzer Security Grapher HTTP Server Reporter HTTPS Managed Devices CIM Server CIM Providers CIMOM CIM Operations over HTTPS Browser Figure 41: An example WBEM implementation. The Client software on a management workstation is a Web browser, supporting user authentication, forms and Java. The user interface is coded using HTML, including requests to the database for network, configuration, statistical or report information. The Web server then receives the data, parses the final HTML code and sends it to the browser with the attachement files, to be displayed on the browser window. The security system takes care of the user authentication and prevents unaccidental or illegal access to confidential information (like router or firewall configurations!). As shown in Figure 42, the CIM interface can be used between an NMS station and the managed element, as well as between two NMS systems. The CIM data is encoded with XML and transported with standard Internet protocols. A WBEM management system can also communicate with legacy SNMP agents, using ASN.1 coded MIB structures, or with propriatory management systems. The WBEM management system provides standard browser interface, using HTML encoding and HTTP/HTTPS protocol. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 79 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Common Browser Interface UI HTTP/HTTPS (HTML) NMS SNMP/MIB (ASN.1) CIM CIM HTTPS/CIM (XML) Propriatory protocols Managed Devices and Systems SNMP Agent CIM Agent Management Agent Figure 42: WBEM standard interfaces, protocols and encoding. WMI (Windows Management Instrumentation) is the Microsoft implementation of WBEM, that includes providers, like registry provider and SNMP provider, between the WMI and operating system, applications and other computer system components. WMI is an integral part of modern Microsoft OSes, and it can be used by desktop management tools, like Microsoft SMS and third party management software. Microsoft also offers free tools, like the WMI Object Browser for Windows 2000, to access the WMI data. As demonstrated in Figure 43, WMI offers very detailed information about Windows 2000 settings. /33/ /34/ /35/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 80 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 43: Accessing information about daylight saving time setting on a Windows 2000 host using Windows Management Instrumentation. 5.3 Directory Enabled Network Initiative 5.3.1 DEN Motivation and Overview Traditional device management systems for data networks provide information about the status of network devices and a general-purpose launch pad for configuration tools (Telnet, Web Browser, TFTP download). Device management systems are based on the assumption that network management intelligence is concentrated on the NMS stations, and the network devices only passively reply on requests. While a single network is used for web surfing, Intranet pages, business critical data applications, real-time voice and video and multicasting video distribution, more and more processing power, intelligence and more complex configurations are needed in devices. Differentiated VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 81 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY services based on user and application data should be offered, and network administrators need detailed access and service level control. DEN (Directory Enabled Network) is DMTF initiative to provide building blocks for more intelligent network management by integrating CIM technologies with a directory to provide a unified system and service management infrastructure. The directory is an excellent way to store all information about system components, organisations, users, resources and management capabilities in a single reposity. Common identities, stored in the directory, may be used for user authentication and profiling, providing differentiated services and inventories. All data about users, user authentication, resources, user rights, organisation structure and network devices may be concentrated on a single directory, and network access devices, Client/Server systems and network configuration could use this single directory information, at least in theory. /36/ /37/ DEN is based on an ad-hoc Working Group document by Microsoft and Cisco in 1998. It defines: 1: An extension schema of CIM information model for network elements and services. The DEN information model is repository-independent. 2: Mapping of information to a format that can be stored in a directory using IETF LDAP (Lightweight Directory Access Protocol) or ISO X.500. 5.3.2 DEN Schema The DEN network schema extension specifies a CIM extension for describing static and dynamic information about network elements and services. The DEN Schema includes classes from CIM, X.500 and DEN. DEN integrates existing SNMP, X,500, DNS, DHCP, RADIUS (Remote Authentication Dial-in User Service) and CIM data with DEN extensions and provides an integrated a uniformed information model, shown in Figure 44. Devices or systems managed by DEN don't have to support LDAP or other new protocols. Users, applications and services are abstracted through profiles, that tell the system what should be done. Policies define what resources can be used by a user by an application or a service. A policy instructs network nodes how to manage requests for network resources. X.500 Person represents an employee or remote user, a client for a network service or an owner of a network device or service. Users may be grouped and an organisation is a business entity that includes devices and services. Altogether, DEN Schema forms an extensible service oriented framework. /38/ /39/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 82 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY X.500 Top CIM ManagedSystemElement Configuration Application Person Group Software System Location Check Action Organization Product Service FRU Protocol Profile NetworkDevice NetworkProtocol NetworkMedia Policy LinkedContainer NetworkElement DEN Figure 44: Classes in DEN base schema. (* 5.3.3 Directories A directory is a general purpose data storage to hold information of groups of objects. Objects on a directory are organised hierarchically on a Directory Information Tree. Object has attributes, and each attribute has restrictions and value. Each attribute has at least one Distinguished Name with a value and zero or more nondistinguished values. Data may be retrieved from the directory either by specifying an exact set of criteria (attribute = value) or by a general set of criteria, describing the characteristics of the information. For example, my personal data could be found either by seeking for a person with a familyname of Puska and firstname Matti or by seeking for an Evitech employee working as a teacher in Information Technology study program, giving a course of Network Management Systems. *) Network Device is not an actual class, but an abstraction of changes to existing CIM classes to realize physical characteristics of real world network devices. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 83 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Directories have the following characteristics: • Information is normally read more frequently than written, and performance may be optimized for read and search operations. • Information is stored in a hierarchical fashion. While directory stores objects, the parent-child relationship is based on containments. • Information is based on attributes, and directory schema defines class hierarchy, attributes, attribute types, rules, restrictions and access rights. • A directory provides a unified namespace, and Distinguished Name is used to identify an object. A common namespace makes it possible to integrate different type of information, like users, applications, servers and network devices. • Directories may be distributed by replicating the single master data to multiple physical storage components. On a properly designed distributed directory, data integrity is quaranteed. Currently directories are often used to store and search personal information in a company: organisation hierarchy, empoyee data and contact information. Modern network operating systems organise user base and network resources in directories, like Active Directory (AD) for Microsoft Windows 2000/2003 server and Network Directory Service (NDS) for Novell NetWare. When using standard protocols for the directory and amending it with data about network devices, differentiated services may be offered for users with a single logon. Figure 45 shows an example LDAP namespace hierarchy of Evitech. /38/ /40/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 84 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY LDAP ROOT o= stadia ou= admin uid= Karhu ou= auto ou= bio uid= uid= Komulainen Nuutinen c=se c=fi c=de c=n o= evitech o= ncp o= hamk o= oulu ou= chem ou= dip ou= it ou= media ou= survey ou= People ou= Services ou= Labs ou= Groups uid= Puska uid= Pätynen uid= Sauren uid= Rahkonen Figure 45: LDAP Namespace example. 5.4 Desktop Management Initiative PC workstations consist of many components from different vendors (motherboard, BIOS, OS, RAM, processor, PSU, Bus controller, display adapter, hard drives, CDROM/DVD drive, NIC...) which are assembled either by giant multinational companies or by small garage enterpreneurs. When hardware and software are often upgraded, it becomes impossible to keep a manual inventory of the PC platform in a company. However, up-to-date information about memory, hardware, partitions and BIOS configuration is often needed during an operating system or application software upgrade rollover. Desktop Management Initiative (DMI) is a standard supported by large PC manufacturers and System Management vendors. It defines Application Programming Interfaces (API) which are used by the management software to find out hardware and software component and version information. As shown in Figure 46, DMI is based on distributed client/server architecture, consisting of the following software components and APIs: • Local or remote DMI Browsers provide access to the DMI data from a local application or from a System Management station, providing vendor specific user interface. • Management Interface Client is the counterpart of the DMI Browser. It is used by the management application to access the managed PC. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 85 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • Remote Procedural Call (RPC) is a standard way to run remote procedures. RPC Server acts as a translator between the MI Clients and the MI Server. • Management Interface Server is an API, that enables communication between the MIs and the DMI Service Provider. • DMI Service Provider is the primary software interface from the system management application and the hardware, software and firmware components. • Procedural Component Interface is again an API, that provides communication from the DMI Service Provider to the Procedural Component Instrumentation. • Procedural Component Insrumentations are vendor specific descriptions for the access to the management data of their components. • Management Information Format (MIF) describes the manageable characteristics (=attributes) of hardware, software and firmware components, that make up the computer. HW SW FW DMI Agent DMI Browser Proc. Proc. Proc. C Instr. C Instr. C Instr. Procedural C. Interface DMI Service Provider Mgmt Interface Server RPC Support MI MI Client Client (Local) MIF DB DMI Browser Figure 46: Desktop Management Interface. System management software, like HP OpenView, IBM NetView and Microsoft Systems Management Server offers support for DMI. Normally they save the workstation details in a database. Other system management tools include Unicenter TNG from Computer Associates and Tivoli TME from IBM. These are system solutions for IT which cover the network infrastructure, Windows, Win NT/2000 and UNIX workstations, servers, software components and service networks. For example, the user interface in Unicenter is based on application sceneries, providing information about systems serving business processes. Also the HP OpenView has developed as a general concept in system management, covering network devices, workstations, printers, servers and client/server systems. /31/ SNMP and CIM network management frameworks can be integrated by mapping the DMI data to SNMP Object Id's.. This is done by external DMI Subagent, DPI interface VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 86 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY (Distributed Protocol Interface) to the SNMP Agent and mapping files on the PC. In this way the DMI data may be accessed from an SNMP management console. 5.5 Common Information Model 5.5.1 Overview CIM (Common Information Model) is a formal way of representing real world hardware and software elements. It follows the principles of object oriented modelling, including classes, that describe types of things, and instances, that are things with a defined type. Normally CIM is presented graphically with UML (Unified Modeling Language) and coded with Managed Object Format (MOF). A CIM Schema is an abstract model of an existing thing. A schema consists of a group of classes with a single owner, and it is used for administration and class naming. The basic CIM schema consists of the following components: • CIM Core Model, general information model for all domains of management. The core model includes general purpose classes, like CIM_ManagedSystemElement, CIM_PhysicalElement and CIM_LogicalElement, CIM_LogicalDevice and CIM_System. • CIM Common Models, seven information models common to particular management domains, but independent of technology. The Common Models include Systems, Applications, Devices, Users, Networks, Policies and Databases, defining classes like CIM_OperatingSystem and CIM_Service. • CIM Extension Models, representing technology specific extensions of the Common Model. Extension models are specific to environments, like operating systems or device vendors. 5.5.2 Classes, Properties and Methods The root class on the CIM Core Model is CIM_ManagedElement. This abstract class includes only a few properties, i.e. class characteristics, namely Caption and Description, which are inherited by the subclass CIM_ManagedSystemElement, which again has subclasses CIM_PhysicalElement and CIM_LogicalElement. Subclasses may introduce new properties, like Name, Status and InstallDate for CIM_ManagedSystemElement. Classes may also have methods, which describe the behavior of a class. An example is the Reset() method of CIM_LogicalDevice, which includes also other methods. Subclasses inherit properties and methods from their VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 87 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY superclasses, but they may override the superclass definition, if necessary. Class inheritance hierarchy is normally presented in the UML diagram with blue lines with arrows pointing to the superclass. Figure 47 presents the class hierarchy of the CIM Core Model. In the UML, a class is presented with a rectangle with two or three regions, the uppermost for the class name, the second for properties, if any, and the third for methods, if any. ManagedElement Caption Description Collection Product Configuration StatisticalInformation Setting ManagedSystemElement Name: string Status: string InstallDate: datetime PhysicalElement LogicalElement Manufacturer … LogicalDevice DeviceID Reset() System Roles … Figure 47: Class hierarchy of the CIM Core Model. CIM_ at the beginning of each class name is omitted. A property is named with a list of the Schema, the Class and the Property, like CIM_LogicalDevice.DeviceID which may hold any string variable, for example an IP address. CreationClassName property defines the class of an instance. 5.5.3 Aggregatations and Associations A CIM entity may be made up of aggregation of one or more other entities. An aggregation has a name, its participants have roles, and an aggregation may have restrictions about the number of participants on a specific role. For example, a System may consists of multiple LogicalDevices acting as SystemDevices. In UML, aggregation is often presented with green lines with a square showing the end of the larger entity and the aggregation name near the center of the line. The allowed number of entities on a specific role is also presented (1 for a single system, * for multiple LogicalDevices in case of the SystemDevice aggregation). VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 88 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Another relation between entities is association, which presents a relationship between two or more objects. In CIM, an association really is a class with references, but it doesn't affect the related classes. A reference is a pointer to other instances, and it defines the role of an object on an association. In UML associations are presented with red lines with the association name in the center and number of entities indicated in both ends of the reference. Examples of associations are zero or one default setting, multiple element settings and multiple element configuration for a CIM_ManagedSystemElement. Figure 48 presents the full CIM Core Model with classes, class inheritance, aggregations and asociations. We should pay attention to the separation of physical and logical elements of the CIM_ManagedSystemElement and to the fact that statistics is an association between a ManagedElement and StatisticalInformation. * ProductParentChild Collection Product MbrOf Coll. Dependency * ManagedElement * Statistics * Configuration Setting Context * Product Physical E´lements StatisticalInformation ManagedSystemElement * Component * * * Rel. Stats. Setting Element Config. ElementSetting * * * 0...1 DefaultSetting * LogicalElement * Logical Synchronized Identity * * PhysicalElement * Realizes * SystemDevice LogicalDevice System Figure 48: CIM Core Model. 5.5.4 Common Models The CIM Common Models are information models for technology independent elements common to a particular management area, and they can be used as a basis for management application development. Common Models profide base classes for the following management areas: VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 89 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY • Systems, describing top-level system objects for a management environment, presenting computer, application and network systems. The Systems Model expands the CIM_LogicalElement with CIM_LogicalDevice, CIM_OperatingSystem, CIM_Service and CIM_System classes with subclasses. • Devices model discrete logical units on a system, not physical. The Devices Model introduces subclasses CIM_UserDevice, CIM_Controller, CIM_MediaAccessDevice, CIM_StorageElement, CIM_PowerSupply, CIM_NetworkAdapter and CIM_Processors for the CIM_LogicalDevice, presented by the System Model. • Applications model represents details for software products and applications. The application model uses the idea of application life cycle from Deployable, Installable, Executable to Executing stages. The applications model also includes association between a CIM_LogicalElement and CIM_Product. Product is not a subclass of ManagedSystemElement, but a unit of purchasing and licensing emphasizing the commercial aspect. • Networks model represents aspects of the network environment, like network topology, connectivy, protocols and services. • Physical model provides representations of the actual physical environment. Physical parts are not directly instrumented, but manipulated by logical system elements, so most of the management environment is presented in logical objects. 5.5.5 Extensions Technology and vendor specific extensions to CIM Common model are encouraged. For an extension model, a schema and class definitions are needed. For example Microsoft CIM studio makes it possible to examine and create CIM classes. As shown in Figure 49, the CIM Common Model includes class hierarchy of CIM_ManagedSystemElement, CIM_LogicalElement, CIM_LogicalDevice and CIM_Battery. The Microsoft Win32 extension to this includes for example Win32_Battery with a subclass Win32_PortableBattery, including properties, methods and associations. As shown in the Figure, the methods of Win32_PortableBattery include Reset and SetPowerState, which are reasonable functions for a battery of a laptop computer. /31/ /41/ VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 90 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Figure 49: Some Win32 extensions to CIM Common model by Microsoft. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 91 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 5.6 Summary Figure 50: Summary of Chapter 5. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 92 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Review Distributed Managent Task Force is an industry organisation, founded in 1992, that promotes advanced management standards for desktop, enterprise and Internet environments. Some DMTF standards are widely approved and implemented, while other are still in development phase. Web Based Enterprise Management (WBEM) is a unified NMS method for large complex enterprise networks, based on the idea that modern network components have much processing power, detailed information of their status and possibility to take an active role on network management. A WBEM system consists of a CIM Client with a Web browser, making requests, and CIM servers, listening for requests and returning replies. A CIM server is a software component on managed devices, and consists of CIM Object Manager (responsible of communication), providers (providing interface to the network component) and CIM information model. The CIM interface may be used between a network management system and managed components or between two network management systems. A real WBEM implementation includes a manager system, a Web server with manager information reposity, a workstation with a Web browser, and of course managed network elements with CIM Server. Directory Enabled Network initiative looks networks as a whole, including resources, services, users and service levels. The focal point is an LDAP directory, which stores network related information. DEN schema includes classes from CIM, X.500 and DEN and forms an extensible service oriented framework. Desktop Management Initiative is a standard, that defines an API for finding detailed information about hardware and software components and settings on PC workstations and servers. DMI Service Layer and Component interface on a DMI supporting host provides possibility to retrieve static information through Management Information Files and dynamic information through component agents. Most system and desktop management software implement DMI and many large PC manufacturers offer DMI support on their devices. Common Information Model is an object oriented way to represent real world hardware and software components. The CIM Schema consists CIM Core Model, Common Models and Extension Models, and defines a set of classes. A class has a name and optional properties and methods, which are inherited by the subclasses. Relation between entieties are called associations and entities may be aggregated of one or more of other entities. The Core Model defines a general information model, and more detailed information of a particulat management domain is defined in Common Models for Systems, Applications, Devices, Users, Networks, Policies and Databases. Technology or vendor specific extensions are encouraged. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 93 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Quiz • Name a few founders of Distributed Management Task Force. • How are the roles of an industry organisation, like DMTF, and a standardisation organisation, like IETF, different? • List the six DMTF initiatives. • What is the purpose of Web Based Enterprise Management? • List the system components on a CIM server, which listens for requests from CIM Clients and reply with the requested data. • How is the CIM data encoded? • List the two usage areas for CIM interface. • From which standards does the DEN Schema include classes from? • Can DEN be used for user authentication? • Can DEN be used for providing different services for different user groups? • How is static hardware information provided in Desktop Management Initiative? • How is dynamic hardware and software information provided in DMI? • What does Common Information Model represent? • What do CIM Common Models cover? • What does a Method of a class describe? • What does a Property of a class describe? • What is inheritance in the CIM context? • What are the CIM Extension Models for? VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS DISTRIBUTED MANAGEMENT TASK FORCE 94 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 6 List of Acronyms A AAL5 ACS ACSE AD AI API ARP ASCII ASF ASN.1 AT ATM ATM Adaptation Layer 5 Association Control Service Access Control Service Environment Active Directory Artifical Intelligence Application Programming Interface Address Resolution Protocol American Standard Code for Information Interchange Alert Standard Format Abstract Syntax Notation One Address Translation Asynchronous Transfer Mode B BIOS Basic Input/Output System C c CA CCITT CEO CGI CIM CIMOM CLNP CLTP CMIP CMIS CMISE CMOT CONP COTP CPU Country Certificate Authority Comité Consultatif International Télégraphique et Téléphonique Chief Executive Officer Common Gateway Interface Common Information Model CIM Object Manager Connectionless-Mode Network Protocol Connectionless-Mode Transport Protocol Common Management Information Base Common Management Information Services Common Management Information Service Element CMIP over TCP/IP Connection Oriented Netwrok Protocol Connection Oriented Transport Protocol Central Processing Unit VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF ACRONYMS 95 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY CRC Cyclic Redundancy Check CSMA/CD Carrier Sense Multiple Access Collision Detect D DB DCN DDNS DEN DHCP DMI DMTF DN DNS DoD DPI Database Data Communication Network Dynamic Domain Name System Directory Enabled Network Dynamic Host Configuration Protocol Desktop Management Initiative, Definition of Management Information Desktop Management Task Force Distinguished Name Domain Name System Department of Defence Distributed Protocol Interface E EDP EGP EMS ETSI Electronic Data Processing Exterior Gateway Protocol Element Management System European Telecommunication Standards Institute F FCS FTAM Frame Chech Sequence File Transfer and Access Method G GDMO GMT GPRS GSM GUI Guidelines for the Definition of Managed Objects Greenwitch Mean Time Generalized Packet Radio System Groupe Spécial Mobile Graphical User Interface H HTML HTTP HTTPS Hypertext Markup Language Hypertext Transfer Protocol Secure Hypertext Transfer Protocol VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF ACRONYMS 96 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY I ICANN ICMP ID IDE IETF INMS IP ISO ISP ITU Internet Corporation for Assigned Names and Numbers Internet Control and Message Protocol Identification Integrated Development Environment Internet Engineering Task Force Integrated Network Management System Internet Protocol International Standardisation Organisation Internet Service Provider International Telecommunications Union J JMAPI JTC1 Java Management Application Programming Interface Joint Technical Committee 1 L LAN LATA LDAP LLC Local Area Network Local Access Transport Area Lightweight Directory Access Protocol Logical Link Control M MAC MAU MD MIB MIF MIT MML MMS MOF MRTG MSB MTBF MTTR MTU Medium Access Control Multistation Access Unit Mediation Device Management Information Base Management Information File Management Information Tree Man-Machine Language Multimedia Message System Managed Object Format Multi Router Traffic Grapher Most Significant Bit Mean Time Between Failures Mean Time To Repair Maximum Transmission Unit N NDS NE NIC NMC Network Directory Service Network Element Network Interface Card Network Management Center VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF ACRONYMS 97 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY NMS NOC NOS Network Management System Network Operations Center Network Operating System O o OID OS OSI OSS ou Organisation Object Identifier Operating System, Operations System Open Systems Interconnection Operations Support System Organisation Unit P PaBX PDU PSU Private area Branch Exhange Protocol Data Unit Power Supply Unit Q QA Q Adapter R RADIUS RAM RFC RMON ROSE RPC Remote Authentication Dial-in User Service Random Access Memory Request for Comment Remote Monitoring Remote Operation Service Remote Procedure Call S SDH SMBIOS SMI SMP SMS SNMP SSL Synchronous Digital Hierarchy System Management BIOS Structure of Managemen Information Simple Management Protocol System Management Server Simple Network Management Protocol Secure Socket Layer T TCL TCP TCP/IP TFTP TMN Tool Command Language Transmission Control Protocol Transmission Control Protocol/Internet Protocol Trivial File Transfer Protocol Telecommunication Management Network VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF ACRONYMS 98 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY TO0 TP 4 Transport Protocol 0 Transport Protocol 4 U UDP uid UML UMTS UPS UTC User Datagram Protocol User Identification Unified Modeling Language Universal Mobile Telecommunication System Uninterruptable Power Source Universal Time Convention V VLAN VoIP VPN Virtual LAN Voice over IP Virtual Private Networks W WAN WBEM WMI Wide Area Network Web-based Enterprise Management Windows Managemen Instrumentation X XML Extensible Markup Language 3 3G 3rd Generation VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF ACRONYMS 99 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY App A This appendix includes: • The TCP/IP Protocol Stack • SNMP Message and PDU Formats • Other Central TCP/IP PDUs • Ethernet and 802.3 Frame Formats • LLC1 Frames Protocol Data Units TCP/IP Protocol Stack TCP/IP Architecture divides communication tasks into three layers. Each layer realisation on an End System or on an Intermediate System communicates with the peer entity using a protocol. Figure 51 shows the central TCP/IP protocols. The application layer protocols generate messages that are transported on the payload field of transport layer segments or datagrams. The transport layer PDUs are then enclosed to Internet layer packets. The packets are send to an Interface that is not part of the TCP/IP architecture. The Interface can be a packet or a circuit switched network. T e l n e t F T P P O P S M T P H T T P D N S I R C TCP S N M P X 1 1 R T P UDP OSPF RIP IP IGRP ARP Interface Figure 51: TCP/IP Protocol Stack. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS PROTOCOL DATA UNITS 100 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Both version 1 and 2c SNMP messages contain a version number, a Community string and an SNMP PDU. The whole message, including the PDU, is coded using ASN.1. The Protocol Data Unit contains ASN.1 tag description and value pairs, as shown in Figure 52. Version Community PDU Request Type Id Error Status Error Index Variable Bindings Figure 52: SNMP Message is ASN.1 coded. SNMP v.1 and v.2c messages are sent in clear text format, while version 3 messages can be encrypted. An authenticated SNMP v.3 message contains, in a digest, a checksum known only to the source and the destination. A private and authenticated format SNMP v.3 message is encrypted with a secret key, known only to the parties. SNMP Network Management messages are transported using the connectionless UDP transport that offers unreliable transport services. UDP sessions are identified by source and destination TCP port numbers. The SNMP agent listens to a well-known port (161 for SNMP), and issues a return port to the client application. The UDP header is protected with a checksum, as shown in Figure 53. 1 Word = 4 B 2 Words 1B Source TCP Port Destination TCP Port Length Checksum Payload Figure 53: UDP Datagram Format. As shown in this figure and in Figure 54, the TCP/IP protocols use 32 bit words. An IP packet header is at least five words (20 bytes), containing an optional variable lenght options field. The header includes also a protocol field which contains information about the upper layer PDU, which is carried in the payload field. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS PROTOCOL DATA UNITS 101 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 1 Word = 4 B 1B 5 - n Words Ver. IHL Type Total Length Identification TTL Flags Protocol Sequence Nr. Checksum Source IP Address Target IP Address Options Padding Payload Figure 54: IP Packet. Ethernet V.2 and 802.3 Frames In Ethernet LANs, upper layer PDUs are carried in either Ethernet V.2 or 802.3 frames. An IP packet is directly encapsulated in an Ethernet frame which contains an EtherType protocol identification, as shown in Figure 55. An 802.3 frame carries an 802.2 LLC frame with a protocol identification for standard protocols, and the layer 3 packet is placed in the payload field of the LLC frame. For non-standard protocols, a separate SNAP frame with an EtherType protocol identification. 6 byte hardware coded MAC addresses are used both in Ethernet and 802.3 frames. In both cased the data field is 46 - 1500 bytes, so the contents of an 802.3 length field is not more than 1 500. EtherType values are always more than 1 50010, so the two frame types can be distinguished with the value of the third field. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS PROTOCOL DATA UNITS 102 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Destination Destination Address Address Source Source Address Address Length Length Data Data == L3 Packet L3 Packet Data Data == LLC LLCFrame Frame Padding (if needed) FCS FCS FCS FCS 8b 8b 6B 2B 6B Destination Destination Address Address Source Source Address Address EtherType EtherType 46 - 1500 B 802.3 Frame 4B Ethernet V.2 Frame Figure 55: Ethernet and 802.3 Frames. Logical Link Control Frames Some network layer protocols, like ISO IP and NetBEUI, use 802.3 frames. In this case, the Data Link Layer 802.3 frame includes a Data Link Layer LLC frame. For connectionless services, LLC Type 1 is used. This provides a common interface for various LAN technologies and upper layer protocol identification. LLC1 includes unnumbered UI, XID and TEST PDUs. For network layer packets, the UI, shown in Figure 56, is used. Data Data == LLC LLCFrame Frame Padding (if needed) FCS FCS LLC UI Frame DSAP DSAP SSAP SSAP Control Control C/R BC Destination Destination Address Address Source Source Address Address Length Length 1 B1 B 1 B 802.3 Frame Info Info == L3 Packet L3 Packet 8b Figure 56: LLC1 UI Frame inside an 802.3 Frame. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS PROTOCOL DATA UNITS 103 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY App B ASN.1 Basic Encoding Rules This appendix includes: • ASN.1 BER Encoding Format • Applying BER Encoding Rules • Meaning of each bit in the Tag field • Most important BER Tag Values BER Encoding Application Layer SNMP Messages are encoded using ASN.1 Basic Encoding Rules. According to BER, all ASN.1 data items are encoded using the format of the following three fields, as shown in Figure x: • One byte Tag field, including information about the ASN.1 data type, class and type format (simple or constructed). • One byte Length field, indicating the length of the value field in octets. • Variable length Value field, including either a single value (of the type indicated by the tag field) or a structured array of multiple values. 1B 1B Variable length Tag Length Value Figure 57: ASN Basic Encoding Format. In case of structured SNMP messages, BER encoding is first applied to the whole SNMP Message. Then the same encoding is applied to the three SNMP Message fields, namely to Version, Community and PDU. On the next step, the BER encoding is applied separately to all PDU fields (Request Id, Error Status, Error Index, Variable Bindings), next to the Variable Bindings, then variables and finally to both the Object Id field and the Value field of each of the Variables. The BER rules result to a nested structure of Figure 57 formats, as shown in Figure 58. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ASN.1 BASIC ENCODING RULES 104 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY SNMP Msg SNMP Msg Tag Length SNMP Message Value Version Community Version Version Version Tag Length Value PDU Value Community Community Community Tag Length Value PDU Tag PDU Length PDU Value Request Error Error Id Status Index Tag Length Value Tag Length Value Tag Length Value Variable Binding Tag Length Value Var Var Variable Tag Length Oid Val Tag Length Oid Tag Length Val Figure 58: Nested BER Encoding of an SNMP Message. Tag Field Values The two most significant bits of the Tag field, bits 8 and 7, indicate data classes, namely Universal (00), Application wide (01), Context specific (10) and Private (11). For SNMP Message and PDU field identifications as well as for simple data types the Universal class is used. Context specific class is used for constructed data types, like PDU value and PDU Types. The next bit, bit 6 indicates simple (0) or constructed (1) format. Constructed format is used for the SNMP Format, PDU, PDU type, Variable Binding List, Variables on the list and for sequences, and the remaining values use simple type. The remaining five least significant bits (bits 5, 4, 3, 2 and 1) indicate the data type in question. Table 2 includes a summary of the most important tag values. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ASN.1 BASIC ENCODING RULES 105 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY Table 2: Some common BER Tag values. MSB Bits 8&7 Type Bit 6 LSB Bit 5, 4, 3, 2, 1 Hex value Message GetRequest PDU GetNextRequest PDU GetResponse PDU SetRequest PDU Trap PDU 00 10 10 10 10 10 1 1 1 1 1 1 1 0000 0 0000 0 0001 0 0010 0 0011 0 0100 30 a0 a1 a2 a3 a4 Version Community PDU Request Id Error Status Error Index Variable Bindings Variable Object Identifier Value 00 00 10 00 00 00 00 00 00 00 0 0 1 0 0 0 1 1 0 0 0 0010 0 0100 0 0010 0 0010 0 0010 0 0010 1 0000 1 0000 0 0110 0 0100 02 04 a2 02 02 02 30 30 06 04 Integer Octet String Null Sequence, Sequence of 00 00 00 00 0 0 0 1 0 0010 0 0100 0 0101 1 0000 02 04 05 30 Example Enclosed is a hex dump of an SNMP message. The total message length is 55 bytes. 30 04 07 01 35 40 2b 02 02 c2 06 01 01 f3 01 01 00 35 02 01 04 02 01 05 06 70 01 00 01 02 00 75 62 6c 69 63 a1 28 02 02 01 00 30 1a 30 0b 06 05 00 30 0b 06 07 2b 06 For decoding, we will first regroup the bytes to find out the BER Tags and Length fields. Then we should use the information on Table 2 to identify BER Tags in question. Decoding exposes the following details. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ASN.1 BASIC ENCODING RULES 106 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 30 02 04 a1 02 02 02 30 30 06 05 30 06 05 35 01 06 28 04 01 01 1a 0b 07 00 0b 07 00 00 70 75 62 6c 69 63 40 c2 f3 35 00 00 2b 06 01 02 01 01 02 2b 06 01 02 01 01 01 SNMP Message, 0x35 = 53 bytes Version, 1 byte, = 0, indicating Version 1 Community, 6 bytes, = public GetNextRequest PDU, 0x28 = 40 bytes Request Id, 4 bytes, = 0x40c2f335 Error Status, 1 byte, = 0 Error Index, 1 byte, = 0 Variable Bindings, 0x1a = 26 bytes Variable 1, 0x0b = 11 bytes Object Identifier, 0x07 = 7 bytes Null value, 0x00 = 0 bytes Variable 2, 0x0b = 11 bytes Object Identifier, 0x07 = 7 bytes Null value, 0x00 = 0 bytes Checking the length fields gives the following results: • the SNMP message, excluding the Message Tag and Message Length is 53 bytes. This matches with the total message length of 55 - 2 bytes • the version value is one byte long and the community string is six bytes long, consuming the total of 2 + 1 + 2 + 6 B = 11 bytes • the GetNextRequest PDU length is 40 bytes, which matches with the 53 - 11- 2 bytes = 40 bytes • the variable bindings length is 26 bytes, consisting of two 11 byte variables, each with a two byte header • both variables are 11 bytes, consisting of a 7 + 2 byte OID and two byte Null value • the object identifier is 7 bytes long and the value is zero byte long. For control, I enclose the protocol analyser printout for the SNMP message. You may compare this with the above presented manual decode results. ------------ SNMP Header -----------SNMP: Version = 0 SNMP: Community = public SNMP: PDU = GetNextRequest SNMP: Request identifier = 0x40c2f335 (1086518069) SNMP: Error status = noError (0) SNMP: Error index = 0 SNMP: Object = 1.3.6.1.2.1.system.sysObjectID SNMP: Object = 1.3.6.1.2.1.system.sysDescr VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS ASN.1 BASIC ENCODING RULES 107 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY List of References 1. Matti Puska: Lähiverkkojen tekniikka. Suomen Atk-kustannus, 1999. 2. HP VantagePoint Demo Show. Hewlett-Packard, 2000. 3. J. Case et. al: A Simple Network Management Protocol, RFC 1157. IETF, 1990. 4. J. Case et. al: Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2), RFC 1905. IETF, 1996. 5. U. Blumenthal, B. Wijnen: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3), RFC 2574. IETF, 1999. 6. UCDAVIS MIB on Linux. 7. RMON Explained. Solcom Systems. 8. Matti Puska: Tietokoneverkkojen asennuksesta ja huollosta, C:18. Hamk, 1997. 9. Paul Hershey, Charles B. Silio: Intelligent Monitoring and Control for Telecommunication Networks. Telecommunications International, August 1997 10. Network Management Concepts. cisco Systems, 1996. Internet, <URL: http:// www.dkrz.de/%7Ek202046/em/products/sem/Manuals/dev_guide/network.doc.html> 11. ICM TMN Platform. Internet, <URL: http://www.telecom.ntua.gr/activities/ projects/icm/platform.html> 12. Evolution of management for corporate networks. Siemens, Telcom Report International. Internet, <URL: http://w2.siemens.de/telcom/articles/e0395/ 395helb.htm> 13. M-L Karjalainen: Nokia NMS/2000 User's Guide. NTC TAN 0312/6 en. Nokia, 1998. 22. James W. Hong et.al.: Enterprise Network Traffic Monitoring, Analysis and Reporting Using Web Technology. Journal of Network and Systems Management, Plenum Press, 1999. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF REFERENCES 108 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 23.Susan E. Aldrich, James Herman, Theodore Forbath: The Impact of the Web on the IT Management Software Market. Patricia Seybold Group, 1999. 24. Tobias Oetiker: MRTG. Internet, <URL: http://ee.staff.ethx.ch/~oetiker/ webtools/mrtg/mrtg.html> 25. Tobias Oetiker: Multi Router Traffic Grapher - Configuration File Format. Internet, <URL: http://ee.staff.ethx.ch/~oetiker/ webtools/mrtg/config.html> 26. ROI Constraint: The Impact of Network Underperformance on Return on Investment for Enterprise-Class Applications. Infonet, 2002. 27. Opening Technologies: Network Management Based on International Standards. Opening Technologies, 1992. 28. Kai Koskimies: Oliokirja. Satku - Kauppakaari, Jyväskylä 2000. 29. Remote Monitoring. Cisco Systems, 2002. Internet, <URL: http://www.cisco.com/univercd/doc/cistwk/ito_doc/rmon.htm> 31. DMTF Web pages. Internet, <URL: http://www.dmtf.org> 32. Andrea Westerinen et. al.: DMTF Standards Overview. DMTF 2002 Developer's Conference 33. Andrea Westerinen, Julie Schott: DMTF Standards Overview - WBEM and CIM, September 18, 2002 34. Andrea Westerinen: DMTF Standards Overview - WBEM and CIM. DMTF, 2002. 35. Windows Management Instrumentation Overview. Microsoft TechNet, 2003. Internet, <URL: http://www.microsoft.com> 36. Cisco Systems: Directory-Enabled Networking. Cisco Systems, 2002. Internet, <URL: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/diren.htm> 37. Andrea Westerinen: DEN and WBEM - Extending Web-Based Enterprise Management. DMTF, 2002 38. Steven Judd, John Strassner: Directory Enabled Networks - Information Model and Base Schema. Version 3c. Internet, <URL: http://murchiso.com/den/specifications/directory-enabled-networks-v3-lastcall.pdf> VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF REFERENCES 109 MATTI PUSKA ESPOO–VANTAA INSTITUTE OF TECHNOLOGY 39. DEN-Based Object Modeling and Schema for Policy-Based Networking.. Cisco Networkers, Paris 2000. 40. LDAP Namespace Design. Oswebo State University, 2000. Internet, <URL: http://netwww.oswego.edu/ldap/namespace_design.html> 41. CIM Tutorial. DMTF Education 42. Keijo Tanskanen: Siirtoverkkojen hallintajärjestelmät. Insinöörityö, Evtek 2004 43. J. Richard Burke: Network Management, Concepts and Practice: A Hands-on Approach. Pearson Education, New Jersey, 2004. VANHA MAANTIE 6 02650 ESPOO matti.puska@evitech.fi NETWORK MANAGEMENT SYSTEMS LIST OF REFERENCES 110 MATTI PUSKA