Presentation is loading. Please wait.

Presentation is loading. Please wait.

SNMPv1 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed.

Similar presentations


Presentation on theme: "SNMPv1 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed."— Presentation transcript:

1 SNMPv1 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed in references.

2 Outline  Introduction  SNMP Organization model  SNMP Information model  SNMP Communication model  SNMP Administration model & Security  Conclusion 2

3 Outline  Introduction  SNMP Organization model  SNMP Information model  SNMP Communication model  SNMP Administration model & Security  Conclusion 3

4 Simple Network Management Protocol (SNMP)  SNMP is one of the most widely used network management protocols  In fact SNMP is a management standard not only a protocol  When we say SNMP management, we are really referring to Internet management standard  SNMP communication protocol is a part of the standard  SNMP Goals  Ubiquity  From PCs to Carrier networks  From small to large network elements  Inclusion of management functions should be inexpensive  Small code  Limited functionality  Management extensions should be possible  New MIBs 4

5 SNMP Versions  SNMPv1  The initial version  Performance & Security limitations  SNMPv2  Initially intended to resolve SNMPv1 issues, but  Performance improvement  More standard management information (MIB-II)  SNMPv3  Major focus on security 5

6 Four Key Parts  Structure of Management Information (SMI):  Data definition language for MIB objects  Management Information Base (MIB):  View of agent, set of MOs, some standard MIBs  SNMP communication protocol  Manager  Agent: object info, commands, …  Security and administration capabilities  Major addition in SNMPv3 6

7 SMI: Data Definition Language  We want to ensure that the syntax and semantics of management data are well-defined and unambiguous  SMI is the language in which that information is specified  It does not define what specific data is required for a particular managed network entity  To do this, SMI allows us to use base data types  Higher level constructs, including sequences, objects and modules. 7

8 Management Information Base (MIB)  The MIB can be thought of as a virtual information store, holding managed objects whose values collectively reflect the current state of the network  Managed objects are specified and gathered into MIB modules using SMI  There are now over ~150 standardized MIB modules and many, many more vendor- specific (private) MIB modules 8

9 SNMP Communication Protocol  Two ways to convey MIB information and commands  Manager initiated  A managing entity initiates a request to management agent  The agent receives the request, performs some action, and sends a reply to the request  Typically this is used to query or modify MIB object values within the managed device  Agent initiated  A management agent sends an unsolicited message, known as a trap message, to the managing entity  Usually used to notify a managing entity of an exceptional situation that has resulted in changes to MIB object values 9

10 SNMP Management Models  Organization Model  Relationship between network element, agent, and manager  Hierarchical architecture  Information Model  Uses ASN.1 syntax  SMI (Structure of Management Information  MIB (Management Information Base)  Communication Model  Communication services addressed by messages  Security Model  Security framework community-based model 10

11 Outline  Introduction  SNMP Organization model  SNMP Information model  SNMP Communication model  SNMP Administration model & Security  Conclusion 11

12 Organization Model  Describes components of a network management system, focuses on  Infrastructure  Manager & Agent & Proxies & RMON  Two & Three Tier Architecture  Functions  SNMP Operations  Manager initiated:  Request  Response  Agent initiated:  Trap 12

13 Two-Tier Organization Model  Basic SNMP organization model is two-tier  Single & multiple managers are allowed  There is not any predefined manager for agents  Any manager can manage any agent  Security: Community (password) is needed 13

14 Three-Tier Organization Model: RMON  Managed object comprises network element and management agent  RMON (Remote Monitoring) acts as an agent and a manager  RMON gathers data from MO, analyses the data, and stores the data  Communicates the statistics to the manager 14

15 Three-Tier Organization Model: Proxy  Proxy server converts non-SNMP data from non-SNMP objects to SNMP compatible objects and messages 15 Manager process SNMP UDP IP Network-dependent protocols Network-dependent protocols Network-dependent protocols Network-dependent protocols Mapping function Agent process SNMP UDP IP Protocol architecture used by proxied device Management process Protocol architecture used by proxied device Management station Proxy agent Proxied device

16 SNMP Operations  Operations supported in SNMP are the inspection and modification of variables & notification  Four Services  Get, Set, GetNext, Trap  Five SNMP Messages  GetRequest, SetRequest, GetNextRequest, GetResponse, Trap 16 ManagerAgent(s) Get, Set, GetNext Request Get Response Trap

17 SNMP Operations 17 Get Request Get Response ManagerAgent GetNext Request Get Response Manager Agent Set Request Get Response ManagerAgent Trap ManagerAgent Get GetNext Set Trap

18 System Architecture 18

19 Outline  Introduction  SNMP Organization model  SNMP Information model  ASN.1 review  SMI & MIB  MIB development  SNMP Communication model  SNMP Administration model & Security 19

20 Presentation Problem in NM  Networks are heterogeneous systems  How data are represented?  E.g. Integer in little-endian or big-endian ordering?  We need standard ways of communicating the same information to/from all devices  ASN.1 from the ISO also provides this kind of translation in a more generic form  ASN.1 is very general & complex  SMI also provides this kind of translation for SNMP network management  Subset of ASN.1 which is customized for network mgmt 20

21 Abstract & Transfer Syntaxes 21 Transfer Syntax Encoding Rules Encoding Rules (BER) Local Mapping Local Storage Data Transfer Component Application Component Local Storage Local Mapping User Presentation Mapping User Abstract Syntax ASN.1 The user of data transfer comp. e.g., SNMP, FTP, TELNET for TCP/IP Mechanisms for transfer of data between end systems (e.g., TCP or UDP) Binary representation of data User is concerned with semantics of data Concerned with syntax of data

22 ASN.1 vs. BER Example 22 BER Encoding Birthday Length Contents 30 ?? VisibleString Length Contents 1A 04 "Jane" DayOfYear Length Contents Birthday ::= SEQUENCE { name VisibleString, day DayOfYear } Type Definition using ASN.1 myBirthday Birthday ::= { name "Jane", day 129 } Value Assignment 0A

23 ASN.1: Backus-Nauer Form (BNF)  Definition: ::=  denotes “entity” and the symbol “::=“ represents “defined as”  Primitive definitions:  ::= 0|1|2|3|4|5|6|7|8|9  ::= +|-|x|/  An entity number can be constructed from primitives:  ::= |  Example:  1 is primitive 1  21 is construct of 2 and 1  321 is construct of 3 and 21 23

24 ASN.1: Modules  Group of assignments: Modules  Start with capital letters  Usually modules are built from primitive (atomic) data types (e.g., INTEGER, REAL, etc..)  May use ASN.1 constructs (e.g., SET, SEQUENCE, etc.) 24

25 ASN.1: Modules 25 A module PersonnelRecord (a set of data types) Three construction mechanisms (develop structured data types): Alternatives: CHOICE List: SET and SEQUENCE Repetition: SET OF and SEQUENCE OF Primitives data types Constructs: “list makers” Construct: alternatives

26 Outline  Introduction  SNMP Organization model  SNMP Information model  ASN.1 review  SMI & MIB  MIB development  SNMP Communication model  SNMP Administration model & Security 26

27 SNMP Information Model  Structure of Management Information (SMI)  Management Information Base (MIB)  Managed Object  Scalar  Aggregate or tabular object  Collections of related objects are defined in MIB modules  These modules are written using an adapted subset of ASN.1  Structure of Management Information (SMI) defines that adapted subset 27

28 MIT: Management Information Tree  SNMP MIB has a hierarchal structure  It is called Management Information Tree (MIT)  To group related information  e.g., all information about NIC is grouped as a sub-tree of node corresponding to the NIC  There are two (in fact three including traps) types of node  Leaf node  management parameter & value  Some leaf nodes define traps  Middle node  to group other nodes  Each node has a unique ID in the tree (known as OID):  1) By concatenation the name of (grand) parent nodes & this node  2) By concatenation of the child # of (grand) parent nodes & this node 28

29 29 Defined using SMI

30 MIB Structure  Object identification?  How to construct the MIT  Parent & Child relations 30

31 Object Name & MIT Structure  Each object is uniquely identified through hierarchical naming in MIT  SMI uses two mechanisms altogether  A descriptive name  Example: sysName, uptime, ospfVersion, …  Location of the object in MIT  Each object has a unique parent node  Each node has a unique childe # in the children of its parent  Example: ospfVersion is the first version of ospf 31

32 MIB Structure: Parent Nodes  Does not contain any data  No data type is needed  Used only for grouping related objects  Only to construct the MIT  Name  Location in MIT 32

33 SMI Type for Parent Nodes  OBJECT IDENTIFIER  Is a primitive type  Commonly used syntax internet OBJECT IDENTIFIER ::= { dod 1 }  Alternative syntax internet OBJECT IDENTIFIER STATUS Current Description "The Internet Sub-node" ::= { dod 1 } 33 Descriptive name MIT Location

34 Alternative Naming  All these are the same  internet OBJECT IDENTIFIER ::= {iso org(3) dod(6) 1 }  internet OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)}  internet OBJECT IDENTIFIER ::= { }  internet OBJECT IDENTIFIER ::= {iso org dod internet } internet OBJECT IDENTIFIER ::= { iso org dod(6) internet(1) }  internet OBJECT IDENTIFIER ::= { iso(1) org(3) 6 1 }  internet OBJECT IDENTIFIER ::= { dod 1 } 34

35 MIB Structure: Leaf Nodes  Leaf nodes contain data  Data can be  Simple scalar  Complex structure  The type of the data must be specified  In addition to  Name  MIT Location 35

36 Object Data Type  Although SMI is based on ASN.1, it has its own types, examples:  INTEGER, Integer32, Unsigned32, OCTET STRING, OBJECT IDENTIFIER, IPaddress, Counter32, Counter64, SEQUENCE, …  Subtype:  INTEGER (0..255), OCTET STRING (SIZE )  Enumeration error-status INTEGER { noError(0) tooBig(1)} 36

37 Application-Wide SMI Types IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER ( ) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER ( ) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER ( ) Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING [ms] A

38 SMI Structured Types  SEQUENCE, SEQUENCE OF :  SET, SET OF, CHOICE of ASN.1 are not included in SNMP-based management  Usually used to construct tables or two- dimensional arrays of other types of data  An individual row is a SEQUENCE, defining the different types making up the various columns  A collection of rows forming the table is made using a SEQUENCE OF construct  It must be a sequence of the same type  Example: TCP connection table 38

39 SMI Type for Leaf Nodes  OBJECT-TYPE : Used to specify managed objects  Includes the data type, status, and semantics  The OBJECT-TYPE construct has four parts:  SYNTAX : The basic data type associated with the object (Only one data type per object in SMI!)  MAX-ACCESS : Whether the object can be read, written, created, or used in a notification  STATUS : Whether the object definition is current, obsolete (for historical purposes), or deprecated  DESCRIPTION : A human-readable definition of the object, giving all necessary semantic information 39

40 SMI: OBJECT-TYPE Example ipInDelivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of input datagrams successfully delivered to IP user- protocols (including ICMP)" ::= { ip 9} 40

41 MIB Structure: Notifications  Notifications are sent by agent to inform manager  Usually contains some objects to be send by the notification  In addition to  Name  MIT Location 41

42 SMI Types for Notifications  NOTIFICATION-TYPE macro is used to define traps  Trap name, OID, Objects, and descriptions TemperatureAlarm NOTIFICATION-TYPE OBJECTS {lowThreshold, highThreshold, currentTemperature} STATUS current DESCRIPTION "This alarm indicates that system temperature violates configured thresholds" ::= { environmentTraps 4} 42

43 MIB Structure: Modules  Modules are high-level optional abstraction layer to group related management objects  Provide some information about the objects  Usually, each HW/SW component is treated as a module, e.g.,  Protocols: IP, TCP, UDP, …  Line Card  Modem  … 43

44 SMI Type for Modules  MODULE-IDENTITY  Allows related objects to be grouped together within a MIB module  It specifies the location of module in the MIT  More over, the MODULE-IDENTITY construct contains clauses that document the module  This includes the author of the module, the data of the last update, a revision history, and a textual description of the module. 44

45 SMI: MODULE-IDENTITY Example ipMIB MODULE-IDENTITY LAST-UPDATED “ Z” ORGANZATION “IETF SNMPv2 Working Group” CONTACT-INFO “Keith McCloghrie ……” DESCRIPTION “The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.” REVISION “ Z” ……… ::= {mib-2 48} 45

46 MIB Structure: MIB  Coarse grain grouping of objects  Related modules are grouped in a MIB, e.g.,  Cisco has it own MIB file(s) containing the modules of Cisco routers  Standard MIBs (e.g., RFC1213) are defined in separated MIB files 46

47 SMI Type for MIB Definition DEFINITIONS ::= BEGIN END  Import is similar to #include in C  IMPORTS MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI  Definitions include  OBJECT-TYPE, OBJECT IDENTIFIER, MODULE-IDENTITY 47

48 MIB Example SIP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, IpAddress FROM SNMPv2-SMI; sipMIB MODULE-IDENTITY LAST-UPDATED " Z" ORGANIZATION "IETF Interfaces Working Group" CONTACT-INFO "... " DESCRIPTION "The MIB module to describe SMDS interfaces" ::= { mib-2 36 } sipMIBObjects OBJECT IDENTIFIER ::= { sipMIB 1 } 48

49 MIB Example sipL3Table OBJECT-TYPE SYNTAX SEQUENCE OF SipL3Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP L3 parameters and state variables, one entry per SIPL3 interface." ::= { sip 1 } sipL3Entry OBJECT-TYPE SYNTAX SipL3Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This list contains SIP L3 parameters and state variables." INDEX { sipL3Index } ::= { sipL3Table 1 } END 49

50 SMI for Organization of a MIB Defined by MODULE-IDENTITY Defined by OBJECT-TYPE Defined by OBJECT IDENTIFIER Defined by NOTIFICATION-TYPE Note: These are currently in used SNMPv1 & SNMPv2 macros (SNMPv2 replaced some SNMPv1 macros) Defined by DEFINITION

51 Managed Object: Single Instance  Object type and data type are synonymous  Object identifier is data type, not instance 51

52 Managed Object: Multiple Instances 52

53 Object Types  Two main object types  According to where multiple instances of objects are  Simple objects  Value is a scalar (Integer, String, …)  Single instance in each node  Examples: System name, Upitme, …  Aggregate objects also called tabular objects  A group of objects  Can be represented by a table with  Columns of objects, Rows of instances 53

54 Aggregate Object Example  IP address table  Consists of objects:  IP address  Subnet mask  Interface  Broadcast address  MTU  Multiple instances of these objects associated (per interface) with the node 54

55 Aggregate Object Type as Table  The objects TABLE T and ENTRY E are objects that are logical objects. They define the grouping and are not accessible  Columnar objects are objects that represent the attributes and hence are accessible  Each instance of E is a row of columnar objects 1 through 5  Multiple instances of E are represented by multiple rows 55

56 Aggregate Object Instances as Table 56 T T.E T.E.1.1T.E.5.1T.E.2.1T.E.3.1T.E.4.1 T.E.1.2T.E.5.2T.E.2.2T.E.3.2T.E.4.2 T.E.1.3T.E.5.3T.E.2.3T.E.3.3T.E.4.3 T.E.1.4T.E.5.4T.E.2.4T.E.3.4T.E.4.4 Row 3: the third instance of the object Not accessible Object ID {Table, Entry, Object, Index } The row # in this example

57 Table Indexing  Index can be anything  Usually a column is used as index not row # 57 The index of table

58 Aggregate Object Example: IP Table  Aggregate M.O. : Table Object 58

59 Aggregate Object Example: IP Table  Aggregate M.O. : Entry Object 59

60 Aggregate Object Example: IP Table  Aggregate M.O. : Columnar Objects ipAdEntAddr OBJECT-TYPE... ::= { ipAddrEntry 1 } ipAdEntIfIndex OBJECT-TYPE... ::= { ipAddrEntry 2 } ipAdEntNetMask OBJECT-TYPE... ::= { ipAddrEntry 3 } ipAdEntBcastAddr OBJECT-TYPE... ::= { ipAddrEntry 4 } ipAdEntReasmMaxSize OBJECT-TYPE... ::= { ipAddrEntry 5 } 60

61 Aggregate Object Example: IP Table 61 Managed objects Their location in the MIB Their data types

62 Aggregate Object Example: IP Table ipAddrTable { } ipAddrEntry (1) ipAdEntAddr (1) ipAdEntIfIndex (2) ipAdEntNetMask (3) ipAdEntBcastAddr (4) ipAdEntReasmMaxSize (5) Columnar object ID of ipAdEntBcastAddr is ( ) iso orgdod internet mgmtmibipipAddrTableipAddrEntryipAdEntBcastAddr

63 Aggregate Object Example: IP Table 63 RowipAdEntAddripAdEntIfIndexIpAdEntNetMaskIpAdEntBcastAddrIpAdEntReasmMaxSize Object instances of ipAddrTable ( ) Columnar ObjectRow #Object Identifier ipAdEntAddr { } ipAdEntIfIndex { } ipAdEntBcastAddr { } IpAdEntReasmMaxSize { } Object Id for specific instances Index of the object instance Object ID for ipAddrEntry Node 1 under ipAddrEntry

64 Standard MIB  Information model of SNMP standard  SMI  Which is discussed  MIB  A set of standard MIBs  The standard MIBs define  The overall structure of MIB  The location of future development is specified  The required management objects must be implemented 64

65 Standard MIBs 65 mgmt (2) directory (1) experimental (3) private (4) Internet { } Reserved for future use Used for objects defined in IAB-approved documents To identify objects used in Internet experiments Used heavily by commercial vendors

66 Standard MIBs 66 mgmt (2) directory (1) experimental (3) private (4) Internet { } mib-2 (1) system (1) interfaces (2) at (3) ip (4) icmp (5) snmp (11) transmission (10) cmot (9) egp (8) udp (7) tcp (6)

67 Standard MIBs 67 mgmt (2) directory (1) experimental (3) private (4) Internet { } enterprises (1) hp (11) cisco (9) 3Com (43) Cabletron (52)

68 Interface Group 68

69 IP Group 69

70 IP Routing Table 70

71 SNMP Information Model Characteristics  Not possible to change the structure of a MIB  In SNMPv2 it is possible to change tables  No explicit action is supported  Action through side-effect of setting a value  Access is provided only to leaf objects in the MIB tree  Not possible to access an entire table or a row of a table with a single atomic action  SNMP MIBs are NOT object-oriented  Inheritance is not supported  These simplify the implementation of SNMP but limit the capability of the NMS 71

72 Outline  Introduction  SNMP Organization model  SNMP Information model  ASN.1 review  SMI & MIB  MIB development  SNMP Communication model  SNMP Administration model & Security 72

73 SNMP MIB Modeling  MIB is essential for developing and operating management systems  Analysis of MIB objects is required before writing MIB definitions  Using the designed model, MIB definitions can be easily generated  Similar to software engineering -- must design a system before any implementation! 73

74 Step 1: MIB Design  Components  Collections of logical & physical component that are being managed  Attributes  Fairly static properties of a modeled object  Statistics  Useful information about what a system has been doing  State  The current condition of a system  Setting  Value of system parameters  Actions  Control a system  Traps  Notifications 74

75 Components  Components  Physical containment  E.g., a list of interface cards  Logical containments  E.g., software components  Start from the top level and work down until reasonable size is reached  Cardinality  How many of an item are present in a system? 75

76 Modeling Example - Router  Containments  Hardware  CPU  RAM  Line Card  NIC  Software  Routing  OSPF  Management  SNMP 76

77 Attributes  The fairly static properties  Typically read-only  Examples  NIC serial number  # Of CPU  Amount of RAM  Manufacture data of router backplane  OSPF version  … 77

78 Statistics  Show a picture of the past (history)  A record of the interesting events which occurred since a specific point in time  Read-only  Examples  # of sent packets  # of dropped packets  # of CPU overutilization  # of OSPF restarts  … 78

79 State  Show the current condition of the resource  Read-only  Stages of operation, examples  Enabled/Disabled state of NIC  Used/Unused MD5 in OSPF  …  Resource usage level, examples  Current routers temperature  Current link bandwidth  Current CPU usage  … 79

80 Setting  The configurable parameters of system  System behavior depends on them  Read-Write  Examples  IP address  OSPF area  CPU over utilized threshold  IPsec parameter settings  … 80

81 Actions  SNMP does not support explicit action operation  Represented in terms of implicit actions which do their work through side effects  This is achieved by setting some value of a MIB object  Typically write-only  Examples  Restart BGP  Ping a remote router  Shut down a NIC  … 81

82 Trap  To notify the manager about the events  No Read, No Write  Examples  Over temperature trap  CPU over utilized trap  BGP route changes (route flapping)  Link over utilization  … 82

83 Step 2: Translate Model into MIB  Each component is modeled as a module: MODULE-IDENTITY  General guide lines  Sub-components with a cardinality > 1 should be part of a table  Attributes of an object can be  Octet String - human readable descriptions or binary data  Integer - measurable quantities  Statistics representing increasing values are Counter type  Stats representing high or low water marks are Integer type  System setting can be any type depends on the setting  Integer for threshold, String for Hostname, IP-Address for address, …  Actions are encoded as Enumerate types  ON (1), OFF (0), START(2), STOP (3), …  Traps also include additional data to be send  States, Setting, and Statistics 83

84 Step 3: Using the MIB  MIB files are complied in both manager & agent software 84

85 Step 3: Using the MIB (cont’d)  Compiling MIB in NMS  Usually, is simply parsing and/or processing  Examples  Simple MIB Browser parses the MIB and display its tree structure  More powerful NMS applications map OIDs to high-level management parameters, e.g.,  OSPF version  Cisco   Juniper 

86 Step 3: Using the MIB (cont’d)  Compiling MIB in Agent  Is developing an executable code from MIB  Based on an existing agent framework  Example  Net-SNMP agent  Implements SNMP protocol (we don’t need to develop it)  Provides an API to develop plug-in (module)  A MIB to read OSPF version is implemented as a module  It uses the Net-SNMP API to connect the agent core  It uses the vendor specific API to access the version of the OSPF 86

87 Outline  Introduction  SNMP Organization model  SNMP Information model  SNMP Communication model  SNMP Administration model & Security  Conclusion 87

88 Communication Model  Architecture  Management messages  SNMP protocol  Packet formats & operation  SNMP protocol MIB  SNMP protocol’s management parameters 88

89 Communication Model: Architecture  Communicate management information between network manager and managed elements  Operation: 5 messages  From manager to agent  get-request, get-next request, set-request  From agent to manager  get-response, trap  SNMP messages are exchanged using UDP (connection less) transport protocol  Port 161: Agent listens for messages from manager  Port 162: Manager listen for trap messages from agents 89

90 SNMP Protocol Message Types 90 GetRequest GetNextRequest Mgr-to-agent: “get me data” (instance or next in list) Message type Function SetRequest Mgr-to-agent: set MIB value GetResponse Agent-to-mgr: value, response to Request Trap Agent-to-mgr: inform manager of exceptional event

91 Communication Model: SNMP Protocol  Message & PDU structure 91

92 SNMPv1 Protocol: Message Formats 92 Variable bindings time stamp specific trap generic trap agent addr enter- prise PDU type Variable bindings error index error status request id PDU type Variable bindings00 request id PDU type SNMP PDUVersionCommunity (a) SNMP message (b) GetRequest PDU, GetNextRequest PDU, and SetRequest PDU (c) GetResponse PDU (d) Trap PDU

93 GetRequest & GetRespone PDU  Is issued by an SNMP manager to retrieve information  Includes PDU type, request-id & variablebindings  GetResponse PDU containing the same request-id is used for the reply  Operation is atomic (all values are returned or none is valid)  If error-status = noError  All variable bindings are valid  If error-status ≠ noError  error-index = index of a variable binding that cause error  None of variable binding is valid  Possible error-status:  noSuchName : object instance cannot be found  tooBig : the size of resulting values exceed a limitation  genErr : Generic error 93

94 SetRequest & GetResponse PDU  Is issued by an SNMP manager to modify information  GetResponse PDU containing the same request-id is used for the reply  if the operation succeeds, a GetResponse PDU is returned with the same variablebindings as in the original SetRequest PDU  The operation is atomic  If any one of the values can’t be set, then the whole operation fails  Manager should re-set the values  However, transaction is not supported  Possible error-status:  noSuchName, tooBig, genErr  badValue : PDU contains at least one pair of variable name and value that is inconsistent 94

95 Trap PDU  Is issued by an SNMP agent to notify NMS of some significant event  Trap PDU does not require a response and is not acknowledged  can get lost  Generic Trap types:  coldStart (0) : unexpected restart due to a crash or major fault  warmStart (1) : routine restart  linkDown (2) : a communication link is inoperational  linkUp (3) : the link is back in operation  authenticationFailure (4) : received authentication-failed  egpNeighborLoss (5) : EGP neighbor is down  enterpriseSpecific (6) : some enterprise-specific event occurred 95

96 GetRequest Issues  Assume browsing the following MIB 96

97 GetRequest Issues (cont’d)  Hidden assumption in the previous example  We know all the elements in MIB including the number of columns and rows in the table  In practice, tables are dynamic  We may don’t know the number or row  If we have MIB, we only know column #  In some situations, we may have not all information about MIB  We just know an object identifier 97

98 Solution for GetRequest Issues  SNMP support two object access modes:  1) Random access: Using the OID  2) Serial access: Using Lexicographical order  Lexicographical ordering is also referred to as:  preorder traversal (root, left, right) of a tree  depth-first search  Useful for examining MIBs whose structure is not known to NMS  It is known as “MIB walk” 98

99 Lexicographical Ordering  Example of lexicographic order of numbers 99

100 Lexicographical Ordering  Example of lexicographic order of MIB Lexicographical order of OIDs MIB

101 GetNextRequest Example 101

102 GetNextRequest & GetResponse PDU  Is issued by an SNMP manager to retrieve information  The PDU is the same as GetRequest PDU except:  In the GetRequest PDU, each variable in the variablebindings list refers to an object instance whose value is to be returned  In the GetNextRequest PDU, for each variable in the variablebindings, the value of the object instance that is next in lexicographic order is returned  Similar to GetRequest, operation is atomic  Allows NMS to discover the structure of a MIB view dynamically  Provides an efficient mechanism for searching a table whose entries are unknown 102

103 Communication Model: SNMP MIB 103

104 Outline  Introduction  SNMP Organization model  SNMP Information model  SNMP Communication model  SNMP Administration model & Security  Conclusion 104

105 SNMP Security Concepts  Authentication service  Agent may wish to limit access to the MIB to authorized managers  Access policy  Agent may wish to give different access privileges to different managers 105

106 SNMP Community  The first version of SNMP had only a simple security functionality, through communities  A pair of manager and agent  Each community  Has a unique name  Also called its community string  A subset of MIB objects available to the community  Also called a MIB view  An access mode (read only or read-write) is defined for each community 106

107 SNMP Community (cont’d)  A managing entity could be part of an agent’s community only by knowing the community name  The name was in effect also the password!  The community name is always sent in the clear (unencrypted) so anyone can sniff it!  Each SNMP agent can define multiple communities  Multiple manager can manage the agent  Different views & access 107

108 SNMP Community (cont’d)  SNMP MIB View  A subset of objects within a MIB  Different MIB views may be defined for each community  The objects in a view need not belong to a single sub-tree  SNMP Access Mode  An access mode {READ-ONLY, READ-WRITE} is defined for each community  The access mode is applied uniformly to all objects in the MIB view  SNMP Community Profile  A combination of a MIB view and an access mode 108

109 Community Profile  Operations on an object determined by community profile and the access mode of the object 109

110 MIB ACCESS Category vs. SNMP Access Mode 110 MIB ACCESS Category SNMP Access Mode READ-ONLYREAD-WRITE read-onlyAvailable for get operation read-writeAvailable for get operation Available for get and set operations write-onlyImplementation-specific Available for set, implementation-specific for get not accessibleUnavailable

111 SNMPv1 Security: Drawbacks  If there is not any attacker!!!, community is a sufficient, but!  No encryption (everything is transferred in plain)  The community string can be sniffed  Attacker will be manager!  Transferred data can be sniffed  no confidentiality  No integrity check  Data modification  invalid management parameters  Not per-user password, community string a shared secret!  If a member of community reveal the string  whole community is compromised  No message stream protection  Replay attack 111

112 SNMPv1 Security (cont’d)  In the end, it was better than nothing at the time, and could be used reasonably  Block SNMP at firewalls to prevent access by all external intruders  Change community strings from default values (usually “public” for read-only and “private” for read-write)  Only allow SNMP requests from certain internal addresses (though addresses could be spoofed)  Use a dedicated line to a device for SNMP access  But, because of security concerns, early SNMP was primarily used only for monitoring  SetRequest was rarely used or supported  No community with read-write access! 112

113 Outline  Introduction  SNMP Organization model  SNMP Information model  SNMP Communication model  SNMP Administration model & Security  Conclusion 113

114 Summary  SNMP (Internet Management system)  SMI (subset of ASN.1): Data type language  MIB: The virtual database of management objects  SNMP protocol: transmit messages  SNMP can be viewed as four models  Organization model: Manager, Agent, Proxy, …  Information model: SMI & MIB  Communication model: get/set/response/ trap  Security model: community profile 114

115 Limitations of SNMPv1  SNMP may not be suitable for the management of truly large networks because of the performance limitations of polling  SNMP is not well suited for retrieving large volumes of data, such as an entire routing table  SNMP traps are unacknowledged & may not be delivered  SNMP provides only trivial authentication  SNMP does not support explicit actions  SNMP does not support manager-to-manager communication Many of these problems are addressed in SNMPv2! 115

116 References  Reading Assignment: Chapters 4 & 5 of “Mani Subramanian, ‘Network Management: Principles and Practice’, Pearson Education, 2012”   R. Dssouli, “Advanced Network Management,” Concordia Institute for Information Systems Engineering, html html  Nhut Nguyen, “Telecommunications Network Management,” University of Texas at Dallas,  J. Won-Ki Hong, “Network Management System,” PosTech University, dpnm.postech.ac.kr/cs607/ dpnm.postech.ac.kr/cs607/ 116


Download ppt "SNMPv1 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed."

Similar presentations


Ads by Google