INTERNET-DRAFT Haresh Khandelwal & Sushrut Deshpande Intended Status: Experimental Cisco Systems Expires: March 2012 SNMPD to use cache and shared database based on MIB Classification draft-haresh-sushrut-mib-classification-01 Abstract This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Haresh,Sushrut Experimental [Page 1] INTERNET DRAFT MIB classification February 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. MIB classification . . . . . . . . . . . . . . . . . . . . . . 3 2.1 How CPU usage goes high . . . . . . . . . . . . . . . . . . 3 2.2 MIB Classification . . . . . . . . . . . . . . . . . . . . . 4 2.3 How SNMP CACHE and SHARED DATABASE works . . . . . . . . . . 4 2.4 How CPU usage reduced . . . . . . . . . . . . . . . . . . . 4 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Haresh,Sushrut Experimental [Page 2] INTERNET DRAFT MIB classification February 2012 1 Introduction Continuous GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST on managed device results into high CPU usage. High CPU usage is result of high process interactions between SNMP process and requested OID's process when OID came from GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST. This draft suggests the way to reduce these process interactions in order to reduce CPU usage. This approach also suggests way to reduce high CPU usage with accurate OID values. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. MIB classification 2.1 How CPU usage goes high When SNMP protocol data units (SNMP PDU) are received by SNMPD running on managed device (router, switch etc...), SNMPD de capsulate PDU and retrieves requested ODI from PDU. After getting OIDs, SNMPD interacts with process under whom requested OIDs and its value reside. For example, NMS sends SNMP GET REQUEST with seeking of interface operational status whose OID is .1.3.6.1.2.1.2.2.1.8. This GET REQUEST PDU is received at managed device's SNMPD which in turn de capsulated PDU and find out that "ifOperStatus" is requested from NMS. SNMPD then interacts with process who handles interface process and gets OID value and builds RESPONSE PDU which sent to NMS. Like as when NMS keeps polling managed device, it leads very high process interactions between SNMPD and requested OID's. generally, process interactions happen through common mechanism like MTS (message transaction service) in NX-OS. processes talk with each other using such messages. so, when processes have to talk with each other frequently, transactions of interaction messages also go very high. such high amount of transactions increase a CPU usage of the system which in turns result into very high CPU usage. SNMP polling is such a method which also leads to high CPU usage of managed device. generally service providers keep monitoring network devices using SNMP for all time and running other application parallel to monitoring it. so if SNMP polling consume higher CPU, it may lead other processes to CPU starvation which may lead device to strange unknown behavior. To avoid this, we are proposing this solution where Haresh,Sushrut Experimental [Page 3] INTERNET DRAFT MIB classification February 2012 we reduce process interactions, so we can achieve less message transactions and less CPU consumption. 2.2 MIB Classification MIB Classification provides a solution to avoid high CPU usage. MIB are classified into two categories. i) Dynamic MIBs - Whose values change frequently (for example ifMIB counters). ii) Relatively Static MIBs - Whose values change occasionally (for example VLAN MIB). 2.3 How SNMP CACHE and SHARED DATABASE works SHARED DATABASE (SDB) is a database where component or process who falls under "Dynamic MIBs" has to populate their supported ODIs values. SNMPD will fetch ODI's value from this SHARED DATABASE when ODI belongs to "Dynamic MIBs" category requested from NMS. Processes taking part in SDB are completely responsible for OIDs values. So, if it is ifMIB counter process for interface then it will be responsible for interfaces counter values in SDB. SNMPD will pickup relevant values for asked OIDs from SDB and will response back to MIB browser/NMS. SNMP CACHING is a database which is maintained by SNMPD of managed device. This database contains ODIs values of "Relatively Static MIBs". These ODI values filled to SNMP CACHE when SNMPD receives ODI's value first time from requested OID's process.SNMPD will form its own cache table which in turn, stores values of all processed ODIs. So when next time same OID will be requested, SNMPD can response from its own Cache table. Now, if value of OID from "Relatively Static MIBs" changes, that process or component has to inform SNMPD regarding its event with new values. SNMPD will update its cache table with new ODI value. SNMP cache table can be flushed in event of SNMP process restart/crash/enable-disable. New cache table will be formed again after recovery with 1st poll cycle. SHARED DATABASE will be handled by individual process and should be populated again in event of process crash/restart. 2.4 How CPU usage reduced For NMS queries with MIB classification approach, SNMPD does not need to talk with individual processes. According to MIB category, SNMP Haresh,Sushrut Experimental [Page 4] INTERNET DRAFT MIB classification February 2012 process will fetch ODIs value from either of these two databases.so, by this way, we can reduce the interaction messages between SNMPD and other processes and still having accurate OID values from accurately maintained database. As high process interactions are reduced, it will reduce CPU usage also. Haresh,Sushrut Experimental [Page 5] INTERNET DRAFT MIB classification February 2012 3 Security Considerations This design is not changing SNMP packets. It does not apply on SNMP SET operation. Communication between NMS and managed device is also un changed, only internal process interaction changes are proposed based on MIB classification.so, this design does not exhibit any security threat. 4 IANA Considerations 5 References 5.1 Normative References 5.2 Informative References [RFC2578] McCloghrie, et al., "Structure of Management Information Version 2 (SMIv2)", RFC2578, April 1999. [RFC3418] Presuhn, et al., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC3418, December 2002. [RFC3411] Harrington, et al., "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC3411, December 2002. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226,May 2008 [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997 Authors' Addresses Name Haresh Khandelwal Sushrut Deshpande EMail: hkhandel@cisco.com, susdeshp@cisco.com Haresh,Sushrut Experimental [Page 6]