Remote Monitoring (RMON)

1. Remote Monitoring (RMON) • RMON specification is primarily a definition of a MIB • RFC 1757/2819 Remote network monitoring management information base (RMON) • RFC 2021 Remote network monitoring management information base II (RMON2) • Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network.

2. Goals (RFC2819 /obsolete 1757 ) • Off-line operation • reduce polling from manager • Proactive monitoring • Monitor can run diagnostics and log network performance (if sufficient resources) • Problem detection and reporting • Active probing of the network • The consumption of network resources • Passively recognize certain error conditions such as congestion on the traffic that it observes • Log the condition and attempt to notify the management station

3. Goals (RFC1757)con’t • Value-added-data • Monitor can perform analyses specific to the data collected on its subnetwork • Analyse subnetwork traffic to determine which hosts generate the most traffic or errors on the subnetwork • Multiple managers • Support more than one manager • To improve reliability, to perform different functions

5. Control of remote monitors • RMON MIB contains features that support extensive control from the management station • 2 categories of RMON MIB features • Configuration • Action invocation

6. Configuration & Active invocation • Configuration • Each MIB group consists of one or more control tables and data tables • Control table – read/write contains parameter that describe the data in data table • Data table – read only contains information that is defined by control table • Action invocation • Some objects in this MIB provide a mechanism to execute an action on the remote monitoring device. • These objects may execute an action as a result of a change in the state of the object.

7. Multiple Manager - Problems • Concurrent requests for resources could exceed the capability of the monitor to supply those resources • A management station could capture and hold monitor resources for long period of time • Resources could be assigned to management station that crashes without releasing the resources

8. Multiple Manager – Solution • Ownership label is used for a particular row of the table • A management station may recognize resources it owns and no longer need • A network operator can identify and negotiate the management station to free the resources • A network operator may have the authority unilaterally to free resources another network operator has reserved • If a management station experiences a reinitialization , it can recognize resources it had reserved in the past and free those it no longer needs

9. Ownership concept • Ownership label contains one or more of the following: • IP address, management station name, network manager’s name, location or phone number • However, the ownership label does not act as a password or access-control mechanism • Therefore, a row can be read-write by the management station who does not own the row

10. Row Addition (1) • A problem can arise when multiple management stations attempt to set configuration information simultaneously using SNMP. • To guard against these collisions, each such control entry contains a status object with special semantics that help to arbitrate among the managers. • If an attempt is made with the row addition mechanism to create such a status object and that object already exists, an error is returned. • When more than one manager simultaneously attempts to create the same conceptual row, only the first can succeed. The others will receive an error.

11. Row Addition (2) • When a manager wishes to create a new control entry, it needs to choose an index for that row. • It may choose this index in a variety of ways, hopefully minimizing the chances that the index is in use by another manager. • If the index is in use, the mechanism mentioned previously will guard against collisions. Examples of schemes to choose index values include random selection or scanning the control table looking for the first unused index. • Because index values may be any valid value in the range and they are chosen by the manager, the agent must allow a row to be created with any unused index value if it has the resources to create a new row.

12. Fig 8.3

13. Good and Bad Packets (1) • RFC 2819 • Good packets are error-free packets that have a valid frame length. • For example, on Ethernet, good packets are error-free packets that are between 64 octets long and 1518 octets long.

14. Good and Bad Packets (2) • Bad packets are packets that have proper framing and are therefore recognized as packets, but contain errors within the packet or have an invalid length. • For example, on Ethernet, bad packets have a valid preamble and SFD, but have a bad CRC, or are either shorter

15. The RMON MIB • RMON (v1) MIB is incorporated into MIB-II with a subtree identifier of 16 (10 groups) • statistics: maintains low-level utilization and error statistics for each subnetwork monitored by the agent • History: record periodic statiscal samples from information available in the statistic group

17. RMON MIB Group (1) • alarm: allow the management console user to set a sampling interval and alarm threshold for any counter or integer recorded by the RMON probe • host:contains counter for various types of traffic to and from hosts attached to the subnetwork • hostTopN: contains sorted host statistics that report that top a list based on some parameter in the host table

18. RMON MIB Group (2) • matrix: show error and utilization information in matrix form • filter:allow the monitor to observe packet that match a filter • (Packet) capture: governs how data is sent to a management console • event: gives a table of all events generated by RMON probe • tokenRing:maintains statistics and configuration information for token ring subnetworks

19. Important note 1 • All groups in the RMON MIB are optional but there are some dependencies • The alarm group require the implementation of the event group • The hostTopN group requires the implementation of the host group • The packet capture group require the implementation of the filter group

20. Important note 2 • Collection of traffic statistics for one or more subnetworks • statistics, history, host, hostTopN, matrix, tokenRing • Various alarm conditions and filtering with user-defined • alarm, filter, capture, event

21. Statistics Group (1) • Fig 8-6

22. Statistics Group (2) • Table 8.2

23. Statistics Group (3)

24. Statistics Group (4) • The statistics group provides useful information about the load and overall health of the subnetwork • Various error conditions are counted such as CRC or alignment error, collision, undersized and oversized packets

25. History Group • The history group is used to define sampling functions for one or more of the interfaces of the monitor • 2 tables • historyControltable – specify the interface and detail of sampling function • etherHistorytable – record data

26. Fig 8.7

28. historyControlTable • historyControlIndex: index of entry which is the same number as used in etherhistoryTable • historyControlDataSource: identify interface to be sampled • historyControlBucketsRequested: the requested number of discrete sampling interval, a default value is 50 • historyControlBucketsGranted: the actual number of discrete sampling interval • historyControlInterval: interval in second, maximum is 3600 (1 hour) ,default value is 1800

29. Sampling scheme • Consider by historyControlBucketGranted and historyControlInterval • Ex. Use the default value of both • the monitor would take a sample once every 1800 seconds ( 30 min) each sample is stored in a row of etherHistoryTable • The most 50 rows are retained

30. Utilization • It calculates on the two counters :ehterStatsOctets and etherStatsPkts • Utilization=100% x [(Packets x (96+64)))+(Ocetsx8)/interval x 107] • 64 bit – preamble • 96 bit – interframe gap • Assume data rate 10Mbps

32. Host Group • To gather statistics about specific hosts on the LAN by observing the source and destination MAC addresses in good packets • Consists of 3 tables: • one control table (HostControlTable) • two data tables (hostTable,hostTimeTable) same information but index differently

33. hostControlTable • hostControlIndex: • identify a row in the hostControlTable ,refering to a unique interface of the monitor • hostControlDatasource: • identify the interface (the source of the data) • hostControlTablesize: • the number of rows in hostTable (hostTimeTable) • hostControlLastDeleteTime: the last time that an entry (hostTable) was deleted

34. Fig 8.9

36. A simple RMON configuration • Fig8.10

37. hostTable • hostAddress: MAC address of this host • hostCreationOrder: an index that defines the relative ordering of the creation time of hosts (index takes on a value 1-N) • hostIndex : the same number as hostControlIndex

38. Counter in hostTable

40. hostTopN Group • To maintain statistics about the set of hosts on one subnetwork that top a list based on some parameters • Statistics that are generated for this group are derived from data in the host group • The set of statistics for one object collected during one sampling interval is referred as report

41. hostTopNControlTable(1) • hostTopNControlIndex : • identify row in hostTopNControlTable,defining one top-N report for one interface • hostTopNHostIndex: • match the value of hostControlIndex ,specifying a particular subnetwork • hostTopNRateBase: • specify one of seven variables from hostTable

42. hostTopNControlTable(2) • Variable in hostTopNRate • INTEGER { hostTopNInPkts (1), hostTopNOutPkts (2), hostTopNInOctets (3), hostTopNOutOctets (4), hostTopNOutErrors (5), hostTopNOutBroadcastPkts (6), hostTopNOutMulticastPkt (7), }

43. hostTopNControlTable(3) • hostTopNTimeRemaining: • time left during report currently being collected • hostTopNDuration: • sampling interval • hostTopNRequestedSize: • maximum number of requested hosts for the top-N report • hostTopNGrantedSize: • maximum number of hosts for the top-N report • hostTopNStartTime: • the last start time

44. hostTopNTable • hostTopNReport: • same value as hostToNControlIndex • hostTopNIndex: • uniquely identify a row • hostTopNAddress: • MAC address • hostTopNRate: • the amount of change in selected variable during sampling interval

45. Report preparation (1) • A management station creates a row of the control table to specify a new report. • This control entry instructs the monitor to measure the difference between the beginning and ending values of a particular host group variable over a specific sampling period • The sampling period value is stored in both hostTopNDuration and hostTopNTimeRemaining

46. Report preparation (2) • The value in hostTopNDuration is static and the value in hostTopNTimeRemaining counts second down while preparing report • When hostTopNTimeRemaining reaches 0 The monitor calculates the final results and creates a set of N data rows • To generate additional report for a new time period, get the old report and reset hostTopNTimeRemainingto the value ofhostTopNDuration

47. Fig 8.12

49. Matrix group • To record information about the traffic between pairs of hosts on a subnetwork • The information is stored in the form of a matrix • Consists of 3 tables • One control table - matrixControlTable • Two data table – matrixSDTable (traffic from one host to all others) , matrixDSTable (traffic from all hosts to one particular host

50. matrixControlTable • matrixControlIndex: • identify a row in the matrixControlTable • matrixControlDataSource: • identify interface • matrixControlTableSize: • the number of rows in the matrixSDTable • matrixControlLastDeleteTime: • the last time that an entry was deleted