1. COMP1706: MOBILE AND NETWORK TECHNOLOGIES Network Management 2
Dr. George Loukas
University of Greenwich,

2. Components of network management on the Internet
Management of most networks is done through the cooperation of three protocols: SNMP, SMI, and MIB
Network management
MIB
SNMP
SMI

3. Network Management Components
Management information base (MIB) creates a collection of named objects, their types, and their relationships to each other in an entity to be managed
distributed information store of network management data (e.g. no. of IP datagram discarded, CSMA errors in an NIC, descriptive information of software version)
Remote monitoring extension (RMON)
Structure of Management Information (SMI) defines the general rules for naming objects, defining object types (including range and length), and showing how to encode objects and values
Data definition language (i.e. semantics) for MIB objects (i.e. data types, rules for writing and revising info etc)
Simple Network Management Protocol (SNMP) defines the format of packets exchanged between manager and agent
It reads and changes the status (values) of objects (variables) in SNMP packets
MIB
SMI
SMI defines the general rules for naming objects, defining object types (including range and length), and showing how to encode objects and values
SMI does not define the number of objects an entity should manage or name the objects to be managed or define the association between the objects and their values
MIB creates a collection of named objects, their types, and their relationships to each other in an entity to be managed
SNMP defines the format of packets exchanged between a manager and an agent. It reads and changes the status of objects (values of variables) in SNMP packets
SNMP

4. Analogies from computer programming
SMI
MIB
Figure Comparing computer programming and network management
SNMP
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010

5. Management overview SMI MIB SNMP Figure 24.4 Management overview
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010

6. MIB View and Access of an Object
A managed object has many attributes - its information base
A user (manager) can view and perform only certain operations on the object by invoking the management agent
The view of the object attributes that the agent perceives is the MIB view
The operation that a user can perform is the MIB access
Managed objects are uniquely defined by a tree structure specified by OSI model
MIB
Network Management: Principles and Practice© Mani Subramanian 2010

7. OSI Management Information Tree
iso International Standards Organization itu International Telecommunications Union dod Department of Defense
Designation:
iso 1
org 1.3
dod 1.3.6
internet
MIB
Object identifiers (OID) are derived from a tree structure, starting at a root (unlabelled).
Below the root are the three main 'trunks' identifying the controlling organisations: iso, ITU, dod.
ISO has defined 'other international organisations' as being under (ISO) sub-tree 3.
One such organisation is the US Department Of Defense (DOD) which is a further sub-tree 6.
The DOD have further defined a sub-tree (1) for the internet community.
TCP/IP was developed by DOD: Defence Advanced Research Projects Agency (DARPA)
Network Management: Principles and Practice© Mani Subramanian 2010

8. MIB Object Identifier MIB Organised by grouping of related objects
Example:
MIB object labeled arrowpoint (2467), which
contains the MIB objects specific to the CSS,
can be labeled:
iso.organization.dod.internet.private.enterprises.arrowpoint or
MIB
CSS: Content Services Switch is a Cisco Switch
Organized by grouping of related objects. The objects of the MIB are arranged in groups - some groups relate to one layer or protocol in the protocol stack and some relate to the system as a whole.
Many quantities/objects are counters of events and represent an accumulation of the number of events seen since the counter was last zeroed.

9. Object identifier
MIB
All objects managed by SNMP are given an object identifier
The object identifier always starts with
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010

10. MIB-2
The Management Information Base, version 2 (MIB-2) is the MIB currently used in network management
Objects are categorised in 10 groups:
system, interface, address translation, ip, icmp, tcp, udp, egp, transmission, and snmp.
Each group has defined variables and/or tables
MIB

11. MIB
Manufacturers create their own extensions to the standard MIBs to provide better functionality for their own products
E.g. when a new router device is released, a MIB extension must be made available to allow network management systems to be aware of this router’s manageable functionality
MIB

12. MIB example: UDP group MIB Figure 24.12 mib-2
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010

13. MIB example: UDP variables and tables
Figure udp variables and tables
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010

14. Indexes for udpTable MIB Value is added to the oid
The GETNEXT command retrieves the next lexicographically higher object from the device.
TCP/IP Protocol Suite© Behrouz A. Forouzan, 2010

15. Uses the ASN.1 standard and notation to:
SMI
Uses the ASN.1 standard and notation to:
name (managed) objects
define type of data stored in an object
Uses BER to encode data for transmission over the network
SMI

16. ASN.1 example
Informal description of personnel record Name: John T Smith Title: Director Employee Number: 51 Date of Hire: 17 September 1971 Name of Spouse: Mary T Smith Number of Children: 2 Child Information Name: Ralph T Smith Date of Birth: 11 November 1957 Name: Susan B Jones Date of Birth: 17 July 1959
SMI

17. ASN.1 description of the record structure
ASN.1 example
ASN.1 description of the record structure
PersonnelRecord ::= [APPLICATION 0] IMPLICIT SET {
Name,
title [0] VisibleString,
number EmployeeNumber,
dateOfHire [1] Date,
nameOfSpouse [2] Name,
children [3] IMPLICIT SEQUENCE OF ChildInformation DEFAULT { } }
ChildInformation ::= SET {
dateOfBirth [0] Date }
Name ::= [APPLICATION 1] IMPLICIT SEQUENCE {
givenName VisibleString,
initial VisibleString,
familyName VisibleString }
EmployeeNumber ::= [APPLICATION 2] IMPLICIT INTEGER
Date ::= [APPLICATION 3] IMPLICIT VisibleString -- YYYYMMDD
SMI

18. ASN.1 Module SNMP MIB Example
SMI
Network Management: Principles and Practice© Mani Subramanian 2010

19. BER: Encoding structure
The encoding is based on the use of type-length-value (TLV) structure
Indicates the ASN.1 type, the class of the type and whether the encoding is primitive or constructed
Represents the value of the ASN.1 type as a string of octets
SMI
Type
Length
Value
Indicates the length of the actual value representation
If the ASN.1 value consists of one or more components, the TLV “value” consists of one or more TLV structures

20. INTERMISSION

21. SNMP
With SNMP, data travels between a managed device and a network management station (NMS) where users remotely manage the network
Information is transferred between the NMS and the managed device through the use of Agents
Values for various variables are kept on the managed device and reported to the NMS as necessary
Each variable is known as a Managed object (defined in a MIB)
SNMP

22. Operations supported by SNMP
Get (Read): used by NMS to monitor managed devices
Examines variables and/or managed objects maintained by managed devices (e.g. device status, error messages)
Set (Write): used by NMS to control managed devices
Changes the values of variables stored within devices
Trap: for managed devices to asynchronously report events to the NMS
Operations not supported by SNMP
It is not possible to add/delete objects in a MIB. Only to get and set their value.
It is not possible to issue commands for an action to be performed
Access is provided only to the leaf objects in the object identifier tree (it is not possible to access an entire table or a row of a table with one action)
SNMP

23. SNMP Protocol Operations
NMS issues a request, and managed devices return responses via MIB  Implemented by using one of four protocol operations: Get, GetNext, GetBulk, Set, and Trap
SNMP

24. SNMP formats
SNMP Message: version number, community name, and one of five types of protocol data units (message types)
Types of SNMP PDUs
GetRequest
GetNextRequest
SetRequest
GetResponse
Trap
GetBulkRequest (SNMPv2)
InformRequest (SNMPv2)
Version
Community
SNMP PDU
SNMP

25. SNMP PDUs (The SNMP message types)
GetRequest: Requests that the agent return the value of the specified object
GetNextRequest: Requests that the agent return the first valid value following the specified object
For example, assume a getNext is executed for ifType ( ). Assuming the first valid instance of ifType is ifType.1 ( ), this is the value that the SNMP agent will return.
GetBulkRequest: Performs the same function as the get request, but allows the manager to query more than one object per request
This is only valid using the SNMPv2c security model
GetResponse: A reply from the SNMP agent to get-request , get-next-request, or get-bulk-request
SetRequest: Requests that the SNMP agent sets the value of the specified object
SNMP

26. SNMP protocol: message types
Trap: It is possible to set a trap for a defined event or condition detected by the SNMP agent. When that condition occurs, the agent sends a trap to the management station - these can be sent at any time so the management station must constantly 'listen' for them (event / interrupt driven)
InformRequest: originally manager to manager messages (nowadays it allows agent to manager communication). Acknowledges the receipt of a trap
Also, not part of SNMP, but widely used by SNMP managers:
Walk: Implements a series of GetNext or GetBulk requests such that an entire sequence of objects is returned to the manager. In each iteration of the GetNext series, the last object returned becomes the next object on which a GetNext is executed. The walk ends when an object is returned that is beyond the scope of the request.
An example of Walk is provided in Figure 17-6 on page 637. [IBM red book]
SNMP

27. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, William Stallings 1999
SNMP PDU sequences
GetRequest PDU
GetResponse PDU
(a) Get values
Manager
Agent
Manager
Agent
GetNextRequest PDU
GetResponse PDU
(a) Get next values
Manager
Agent
(a) Send trap
Manager
Agent
SetRequest PDU
Trap PDU
SNMP
GetResponse PDU
(a) Set values
SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, William Stallings 1999

28. SNMP Trap Message Types
Generic Trap
Type Description (brief)
coldStart(0)
the SNMP entity, acting in an agent role, is reinitializing itself and that its configuration may have been altered
warmStart(1)
the SNMP entity, acting in an agent role, is reinitializing itself such that its configuration is unaltered
linkDown(2)
Failure of one of the communication links
linkUp(3)
One of the links has come up
authenticationFailure(4)
Authentication failure
egpNeighborLoss(5)
Loss of EGP neighbour
enterpriseSpecific(6)
Enterprise-specific trap (defined in the private MIB section)
Generic-Traps for use with the SNMP
Consider how the standard SNMP traps might be defined:
coldStart TRAP-TYPE ENTERPRISE snmp DESCRIPTION "A coldStart trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the protocol entity implementation may be altered." ::= 0
warmStart TRAP-TYPE ENTERPRISE snmp DESCRIPTION "A warmStart trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered." ::= 1
linkDown TRAP-TYPE ENTERPRISE snmp VARIABLES { ifIndex } DESCRIPTION "A linkDown trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration." ::= 2
linkUp TRAP-TYPE ENTERPRISE snmp VARIABLES { ifIndex } DESCRIPTION "A linkUp trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up." ::= 3
authenticationFailure TRAP-TYPE ENTERPRISE snmp DESCRIPTION "An authenticationFailure trap signifies that the sending protocol entity is the addressee of a protocol message that is not properly authenticated. While implementations of the SNMP must be capable of generating this trap, they must also be capable of suppressing the emission of such traps via an implementation- specific mechanism." ::= 4
egpNeighborLoss TRAP-TYPE ENTERPRISE snmp VARIABLES { egpNeighAddr } DESCRIPTION "An egpNeighborLoss trap signifies that an EGP neighbor for whom the sending protocol entity was an EGP peer has been marked down and the peer relationship no longer obtains." ::= 5
SNMP

29. SNMP message encapsulation
The SNMP protocol is typically encapsulated in UDP datagrams
SNMP
Request, Reply or Trap
UDP IP
SNMP

30. SNMP community
SNMP community is a relationship between an SNMP agent and a set of SNMP managers that defines authentication, access control and proxy characteristics
Authentication: the managed node may wish to limit access to the MIB to authorised managed nodes
Access: the managed node may wish to give different access privileges to different management nodes (the combination of SNMP MIB view, and SNMP access mode is an SNMP community profile)
Proxy: a managed node may act as a proxy to other managed nodes. This may involve implementing the authentication service and/or access policy for the other managed systems on the proxy system
The community concept is a local one, defined at the managed system
Authentication: Not very secure. It only checks the community name. This might be ok for get and trap operations but set is more sensitive and might need encryption/decryption, but this is beyond the scope of RFC 1157
Access: provide different categories of MIB access to different management nodes - SNMP MIB view (subset of objects within a MIB) + SNMP access mode (an element of the set {READ-ONLY, READ-WRITE}) = community profile
Proxy: a proxy is an SNMP agent that acts on behalf of other devices. Typically, the other devices do not support TCP/IP and SNMP or we want to minimise the interation between the proxied device and the NMSs
SNMP

31. Network Management: Principles and Practice© Mani Subramanian 2010
SNMP MIB
SNMPv1 MIB has too many objects that are not used
SNMPv2 made obsolete a large number of them
SNMP
Network Management: Principles and Practice© Mani Subramanian 2010

32. SNMPv2 New Messages inform-request get-bulk-request report SNMP
manager-to-manager message
get-bulk-request
transfer of large data
report
not used
SNMP

33. Bilingual Manager / Proxy Server
Compatibility with SNMPv1
Bilingual Manager
Proxy Server
Bilingual Manager expensive in resource and operation
SNMP
Network Management: Principles and Practice© Mani Subramanian 2010

34. SNMP v3 SNMP Key Features of SNMPv3
Modularization of documentation and architecture
Enables the use of SNMPv1 and SNMPv2 with the newly developed SNMPv3
SNMP engine defined
A model for the processing of SNMP messages
New Security features
Secure information to prevent tampering of data
Access control to determine proper access to MIB
Future development with minimum impact on existing operations
SNMP

35. Network Management: Principles and Practice© Mani Subramanian 2010
Security threats
Modification of information
Contents modified by unauthorized user, does not include address change
Masquerade
Change of originating address by unauthorized user
Message stream modification
Fragments of message altered by an unauthorized user to modify the meaning of the message (possible because of UDP)
Disclosure
Tapping and eavesdropping
Disclosure does not require interception of message
Note: Denial of service and traffic analysis are not considered as threats in SNMP
SNMP
Network Management: Principles and Practice© Mani Subramanian 2010

36. SNMP Security
SNMPv1 uses community strings for authentication as plain text (without encryption)
SNMPv2 was supposed to fix security problems, but effort de- railed (The “c” in SNMPv2c stands for “community”)
SNMPv3 has numerous security features:
Ensure that a packet has not been tampered with (integrity)
Ensures that a message is from a valid source (authentication)
Ensures that a message cannot be read by unauthorized users (privacy)
SNMP

37. SNMPv3 Security
The main objective of SNMPv3 was the addition of security for SNMP management
Authentication and privacy of information; authorization and access control
The architecture supports any type of security but IETF SNMPv3 working group has specified a user-based security model
Instead of granting access rights to a community, SNMPv3 grants access to users
Access can be restricted to sections of the MIB (View- based Access Control Module (VACM). Access rights can be limited:
by specifying a range of valid IP addresses for a user or community
by specifying the part of the MIB tree that can be accessed
SNMP

38. Network Management: Principles and Practice© Mani Subramanian 2010
SNMPv3 Message Format
SNMP
Network Management: Principles and Practice© Mani Subramanian 2010

39. Remote Monitoring RMON
For some, the most important addition to the basic set of SMI- MIB-SNMP standards
MIB-II provides local information to individual devices, not for the network as a whole
RMON extends MIB-II to provide the network manager with vital information about the internetwork
No changes in the underlying SNMP protocol, but it provides a significant expansion in SNMP functionality
RMON

40. Network Management: Principles and Practice© Mani Subramanian 2010
RMON MIB
RMON2:
Higher layers (3-7) groups
(rmon 11 - rmon 20)
RMON1:
Ethernet RMON groups
(rmon 1 - rmon 9)
Extension: Token ring extension (rmon 10)
RMON
Network Management: Principles and Practice© Mani Subramanian 2010

41. RMON1 MIB Groups & Tables
Network Management: Principles and Practice© Mani Subramanian 2010

42. RMON
A standard for monitoring and reporting network activity using remote monitors
Remote monitors (or network analysers or probes or network monitors): devices that have been employed to study the traffic of a network as a whole
Implemented as a dedicated device or as a function available on a system with other duties, e.g. Server, but processing and memory resources are dedicated to the monitoring function
The RMON capability provides an effective and efficient way to monitor subnetwork-wide behaviour while reducing the burden both on other agents and on management stations
RMON

43. SNMP Vs. RMON
RMON is an extension of SNMP via management Information Base (MIB) that defines a particular set of MIB objects for use by network monitoring probes
Architecturally, RMON is just one of the many MIB modules that comprise the SNMP Framework
RMON probe (or RMON agent): a system that implements the RMON MIB
The probe has an SNMP agent like all other SNMP agents
It also has a RMON probe process entity that provides the RMON-related functionality, capable of reading/writing the local RMON MIB
RMON

44. RMON
Remote Network Monitoring (RMON): monitoring the state of a network and its nodes through a remote probe
Why?
Significantly reduces SNMP traffic due to local polling
No need for agent to be visible to managers all the time (reduces Ping messages)
Continuous monitoring of individual segments
Has been shown to increase productivity for network administrators
Components:
Data gatherer: a physical device
Data analyzer: processor that analyzes data
RMON does both and reports to a manager
RMON

45. Advantages of Network configuration with RMON
RMON device monitors the local network segment
It reduces the need for agents to be visible at all time
RMON
Monitoring packets (e.g., Ping pkts) may get lost in long-distance communication
Individual segments can be monitored continuously
SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, William Stallings 1999

46. Exercise
An NMS connected to an Ethernet LAN is monitoring a network of 1,000 nodes comprising routers, workstations and other devices. Assume that an average frame size is 500 bytes long for get-request and response messages. The network has been subnetted into 2 subnets of equal size, with a RMON monitoring each subnet. Each RMON monitors the heartbeat of its own nodes by polling the stations every two minutes. Whenever an RMON detects a failure, it sends a trap to the NMS. What is the RMON-related monitoring load on each subnet (in kbps) if there is no failure anywhere in the network?
RMON
Each subnet has 1,000/2 = 500 nodes. Each frame is 500 bytes = 4,000 bits.
For each subnet, there are 500 requests responses = 1,000 frames per two minutes for RMON-related monitoring.
So, the total load due to monitoring is 4000 * 1,000 = 4,000,000 bits per two minutes = 4,000,000/120 = 33,333 bps = 33.3 kbps.