1. Chapter 8 SNMP Management: RMON Network Management: Principles and Practice © Mani Subramanian 2011 1 Chapter 8 SNMP Management: RMON

2. Network Management: Principles and Practice © Mani Subramanian 2011 Objectives  Remote network monitoring, RMON  RMON1: Monitoring Ethernet LAN and token- ring LAN  RMON2: Monitoring upper protocol layers  RMON MIBs for RMON group objects  Case study 2 Chapter 8 SNMP Management: RMON

3. Notes RMON Components RMON Probe Data gatherer - a physical device Data analyzer Processor that analyzes data RMON - Remote Network Monitoring Network Management: Principles and Practice © Mani Subramanian 2011 3 Chapter 8 SNMP Management: RMON

4. Network with RMONs Network Management: Principles and Practice © Mani Subramanian 2011 Notes Note that RMON is embedded in a router for monitoring the remote FDDI LAN Analysis done in NMS 4 Chapter 8 SNMP Management: RMON

5. Remote Network Management Goals [RFC 2819/STD 59] Off-line Operation: A probe can be configured to perform diagnostics and collect statistics continuously, even when communication with the NMS may not be possible or efficient. The probe may notify the NMS when an exceptional condition occurs. Proactive Monitoring: Given the resources available on the monitor, it is helpful for it continuously to run diagnostics and to log network performance. The monitor can notify the NMS of a failure and can store historical statistical information about it. This historical information can be played back by the NMS for further diagnosis into the cause of the problem. Problem Detection and Reporting: The monitor can be configured to recognize conditions, most notably error conditions, and continuously to check for them. When one of these conditions occurs, the event may be logged, and NMSs may be notified. Value Added Data: Because an RMON device is dedicated exclusively to NM functions, and because it is located directly on the monitored portion of the network, it can add significant value to the data it collects. For instance, by highlighting those hosts on the network that generate the most traffic or errors, the probe can give the NMS precisely the information it needs to solve a class of problems. Multiple Managers: An organization may have multiple NMSs for different units of the organization, for different functions (e.g. engineering and operations), and in an attempt to provide disaster recovery. Because environments with multiple NMSs are common, the RMON device has to deal with more than one NMS, potentially using its resources concurrently. Network Management: Principles and Practice © Mani Subramanian 2011 5 Chapter 8 SNMP Management: RMON

6. Notes RMON Benefits Monitors and analyzes locally and relays data → Less load on the network (solicited and unsolicited) Needs no direct visibility of agents by NMS → More reliable information (polling is local) Permits monitoring on a more frequent basis → Faster fault diagnosis (prevent or react to a fault) Increases productivity for administrators (study report) and network availability to users Unsolicited: if abnormal condition (e.g., heavy packet loss) → Send alarm to NMS Case study: under heavy traffic and long-distance communication, packets are lost: → NMS gets no response for pings → NMS assumes the device (agent) is down (wrong interpretation) Network Management: Principles and Practice © Mani Subramanian 2011 6 Chapter 8 SNMP Management: RMON

7. Control of Remote Monitors Remote monitor is implemented either as: –A dedicated device –A function available on a system RMON MIB contains features that support extensive control from the NMS. These features fall into 2 general categories: –Configuration: a remote monitor needs to be configured for data collection. RMON MIB is organized into a number of functional groups. Within each group, there may be one or more control tables and one or more data tables. A control table: is typically read-write, and contains parameters that describe the data in a data table A data table: is typically read-only At configuration time, an NMS sets the appropriate control parameters (add a new row or modify an existing row) to configure the RMON to collect the desired data. To modify any parameters in a control table, it is necessary to first invalidate the control entry (row) → deletion of this row and associated rows in data tables. –Action Invocation: is the use of SNMP Set operation to issue a command. An object is used to represent a command A specific action is taken if the object is set to a specific value. In general, these objects represent states. An action is performed if the NMS changes a state (i.e., value) Network Management: Principles and Practice © Mani Subramanian 2011 7 Chapter 8 SNMP Management: RMON

8. Notes Row Creation & Deletion: EntryStatus (RMON) EntryStatus data type introduced in RMON EntryStatus (similar to RowStatus in SNMPv2) used to create and delete conceptual row. Only 4 states in RMON compared to 6 in SNMPv2 Valid: Operational and measuring data Any NMS authenticated to use the RMON device may use this row of data. Network Management: Principles and Practice © Mani Subramanian 2011 8 Chapter 8 SNMP Management: RMON

9. Row Creation & Deletion: RowStatus (SNMPv2) Notes Status: A new column is added to the conceptual table SYNTAX of Status is RowStatus Value of RowStatus is Enumerated INTEGER Network Management: Principles and Practice © Mani Subramanian 2011 9 Chapter 8 SNMP Management: RMON

10. Row Addition, Modification and Deletion Row Addition: –If a management station attempts to create a new row, and the index object value or values do not already exist, the row is created with status object value of “createRequest(2)” –Immediately after completing the create operation, the agent sets the status object value to “underCreation(3)” –Rows shall exist in the “underCreation(3)” state until the management station is finished creating all of the rows that it desires for its configuration. The management station sets the status object value in each of the created rows to “valid(1)” –If an attempt is made to create a new row, with a “createRequest(2)”status, and the row already exists, an error will be returned. Row Modification and Deletion –A row is deleted by setting the status object value for that row to “invalid(4)” –The owner of the row can then delete it by issuing a SetRequest PDU –A row can be modified by first invalidating the row and then providing the row with new parameter values. Network Management: Principles and Practice © Mani Subramanian 2011 10 Chapter 8 SNMP Management: RMON

11. Transitions of EntryStatus State [RFC 2819/STD 59] A manager is restricted to changing the state of an entry in the following ways: To: → From: validcreateRequestunderCreationinvalid valid OKNOOK createRequest N/A underCreation OKNOOK invalid NO OK nonExistent NOOKNOOK Network Management: Principles and Practice © Mani Subramanian 2011 11 Chapter 8 SNMP Management: RMON

12. RMON MIB Notes All of the groups in the RMON MIB are optional RMON1: Ethernet RMON groups (rmon 1 - rmon 9) RMON1: Extension: Token ring extension (rmon 10) RMON2: Higher layers (3-7) groups (rmon 11 - rmon 20) Network Management: Principles and Practice © Mani Subramanian 2011 12 Chapter 8 SNMP Management: RMON

13. RMON Groups and Functions Notes Probe gathers data Functions Statistics on Ethernet, token ring, and hosts & conversations Filter group filters data prior to capture of data Generation of alarms and events Network Management: Principles and Practice © Mani Subramanian 2011 13 Chapter 8 SNMP Management: RMON

14. RMON1 MIB Groups & Tables Notes Ten groups divided into three categories Statistics groups (rmon 1, 2, 4, 5, 6, and 10)) Event reporting groups (rmon 3 and 9) Filter and packet capture groups (rmon 7 and 8) Groups with “2” in the name are enhancements with RMON2 Network Management: Principles and Practice © Mani Subramanian 2011 14 Chapter 8 SNMP Management: RMON

15. Control and Data Tables Notes Control table used to set the instances of data rows in the data table Values of data index and control index are the same Network Management: Principles and Practice © Mani Subramanian 2011 15 Chapter 8 SNMP Management: RMON

16. Example: Matrix Control and SD Tables Notes matrixSDTable is the source-destination table controlDataSource identifies the source of the data controlTableSize identifies entries associated with the data source controlOwner is creator of the entry Network Management: Principles and Practice © Mani Subramanian 2011 16 Chapter 8 SNMP Management: RMON

17. Ethernet Statistics Group Contains statistics measured by the probe for each monitored Ethernet interface on a device. These statistics take the form of free running counters that start from zero when a valid entry is created. Each etherStatsEntry contains statistics for one Ethernet interface. The probe must create one etherStats entry for each monitored Ethernet interface on the device. Data includes statistics on packet types, sizes, and errors. Capability to gather statistics on collisions of the Ethernet segment (estimation). Number of collisions can be used to generate an alarm when it exceeds a set threshold value. Network Management: Principles and Practice © Mani Subramanian 2011 17 Chapter 8 SNMP Management: RMON

18. Ethernet Statistics Group (cont.) EtherStatsEntry ::= SEQUENCE { etherStatsIndex Integer32, etherStatsDataSource OBJECT IDENTIFIER, etherStatsDropEvents Counter32, etherStatsOctets Counter32, etherStatsPkts Counter32, etherStatsBroadcastPkts Counter32, etherStatsMulticastPkts Counter32, etherStatsCRCAlignErrorsCounter32, etherStatsUndersizePktsCounter32, etherStatsOversizePkts Counter32, etherStatsFragments Counter32, etherStatsJabbers Counter32, etherStatsCollisions Counter32, etherStatsPkts64Octets Counter32, etherStatsPkts65to127Octets Counter32, etherStatsPkts128to255Octets Counter32, etherStatsPkts256to511Octets Counter32, etherStatsPkts512to1023Octets Counter32, etherStatsPkts1024to1518Octets Counter32, etherStatsOwner OwnerString, etherStatsStatus EntryStatus } etherStatsDataSource → This object identifies the source of the data that this etherStats entry is configured to analyze. (e.g., ifIndex.1) Network Management: Principles and Practice © Mani Subramanian 2011 18 Chapter 8 SNMP Management: RMON

19. History Group Consists of two subgroups: –History control group: Controls the periodic statistical sampling of data from various types of networks –History (data) group: Tracks the overall trend in the volume of traffic. Control table (historyControlTable): –Stores configuration entries comprising interface, polling period, etc. –Contains one entry for each sample –If the probe keeps track of the time of day, it should start the first sample of the history at a time such that when the next hour of the day begins, a sample is started at that instant –Short-term and long-term intervals may be specified (two entries). Defaults → 30 seconds and 30 minutes (respectively) Network Management: Principles and Practice © Mani Subramanian 2011 19 Chapter 8 SNMP Management: RMON

20. History Control Table HistoryControlEntry ::= SEQUENCE { historyControlIndex Integer32, historyControlDataSource OBJECT IDENTIFIER, historyControlBucketsRequested Integer32, historyControlBucketsGranted Integer32, historyControlInterval Integer32, historyControlOwner OwnerString, historyControlStatus EntryStatus } historyControlBucketsRequested → The requested number of discrete time intervals historyControlBucketsGranted → The number of discrete sampling intervals historyControlInterval → The interval in seconds over which the data is sampled for each bucket. This interval can be set to any number of seconds between 1 and 3600 (1 hour). Network Management: Principles and Practice © Mani Subramanian 2011 20 Chapter 8 SNMP Management: RMON

21. Ethernet History Group Data table (etherHistoryTable): –Records periodic statistical samples from a network and stores them for later retrieval –Once samples are taken, their data is stored in an entry in a media-specific table –Each such entry defines one sample, and is associated with the historyControlEntry. –Each value is a cumulative sum during a sampling period Data objects defined: –Dropped events, number of octets and packets, different types of errors, fragments, collisions, and utilization. Network Management: Principles and Practice © Mani Subramanian 2011 21 Chapter 8 SNMP Management: RMON

22. Ethernet History Table EtherHistoryEntry ::= SEQUENCE { etherHistoryIndex Integer32, etherHistorySampleIndex Integer32, etherHistoryIntervalStart TimeTicks, etherHistoryDropEvents Counter32, etherHistoryOctets Counter32, etherHistoryPkts Counter32, etherHistoryBroadcastPkts Counter32, etherHistoryMulticastPkts Counter32, etherHistoryCRCAlignErrors Counter32, etherHistoryUndersizePkts Counter32, etherHistoryOversizePkts Counter32, etherHistoryFragments Counter32, etherHistoryJabbers Counter32, etherHistoryCollisions Counter32, etherHistoryUtilization Integer32 } etherHistoryIndex → has same value as historyControlIndex. etherHistorySampleIndex → uniquely identifies the particular sample among all the ones with the same historyControlEntry. etherHistoryIntervalStart → the value of sysUpTime at the start of the interval over which this sample was measured. Network Management: Principles and Practice © Mani Subramanian 2011 22 Chapter 8 SNMP Management: RMON

23. Alarm Group The Alarm Group requires the implementation of the Event group. Periodically takes statistical samples on specified variables in the probe and compares them with a preconfigured threshold. The group contains an alarmTable with a list of configuration entries that define alarm parameters: variable, polling period, and threshold. If a sample of monitored variable ≥ rising_threshold or ≤ falling_threshold → event generated Rising and falling thresholds are specified → generates one event as a threshold is crossed in the appropriate direction and no more events are generated until the opposite threshold is crossed. Sampling type is either the absolute or delta value. (e.g., 1 gigaoctet in the former and 10000 packets in a 10-second interval in the latter). Network Management: Principles and Practice © Mani Subramanian 2011 23 Chapter 8 SNMP Management: RMON

24. Alarm Table AlarmEntry ::= SEQUENCE { alarmIndex Integer32, alarmInterval Integer32, alarmVariable OBJECT IDENTIFIER, alarmSampleType INTEGER, alarmValue Integer32, alarmStartupAlarm INTEGER, alarmRisingThreshold Integer32, alarmFallingThreshold Integer32, alarmRisingEventIndex Integer32, alarmFallingEventIndex Integer32, alarmOwner OwnerString, alarmStatus EntryStatus } alarmInterval → The interval in seconds over which the data is sampled and compared with the rising and falling thresholds. alarmVariable → The object identifier of the particular variable to be sampled. alarmSampleType → absoluteValue(1), deltaValue(2) alarmValue → The value of the statistic during the last sampling period. –This is the value that is compared with the rising and falling thresholds. –If (sample type is deltaValue) → alarmValue = difference between the samples at the beginning and end of the period. –If (sample type is absoluteValue) → alarmValue = sampled value at the end of the period. Network Management: Principles and Practice © Mani Subramanian 2011 24 Chapter 8 SNMP Management: RMON

25. Host Group Contains information about the hosts on the network. Compiles a list of hosts by looking at the good packets traversing the network and extracting the source and destination MAC addresses. Maintains statistics on these hosts. Comprises three tables: –hostControlTable: controls interfaces on which data gathering is done. –hostTable: contains statistics about the hosts (indexed by the control index and host’s MAC address). –hostTimeTable: contains the same data as hostTable, but stored in time order of its discovery. Index values are more predictable (1 → table_size) Used for fast download of table content and fast discovery of new hosts in the system Network Management: Principles and Practice © Mani Subramanian 2011 25 Chapter 8 SNMP Management: RMON

26. HostTopN Group Requires the implementation of the Host group. Generates reports ranking the top N hosts in selected statistics categories. The available statistics are samples of one of their base statistics, over an interval specified by the management station. The management station selects how many such hosts are reported. hostTopNControlTable is used to initiate generation of a report. The management station may select the parameters of such a report, such as which interface, which statistic, how many hosts, and the start and stop times of the sampling. When the report is prepared, entries are created in the hostTopNTable. Network Management: Principles and Practice © Mani Subramanian 2011 26 Chapter 8 SNMP Management: RMON

27. HostTopN Group (Cont.) hostTopNControlTable hostTopNRateBase OBJECT-TYPE SYNTAX INTEGER { hostTopNInPkts(1), hostTopNOutPkts(2), hostTopNInOctets(3), hostTopNOutOctets(4), hostTopNOutErrors(5), hostTopNOutBroadcastPkts(6), hostTopNOutMulticastPkts(7) } hostTopNTable hostTopNIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION “An index that uniquely identifies an entry in the hostTopN table among those in the same report. This index is between 1 and N, where N is the number of entries in this table…” hostTopNRate OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION “The amount of change in the selected variable during this sampling interval. The selected variable is this host's instance of the object selected by hostTopNRateBase.” Network Management: Principles and Practice © Mani Subramanian 2011 27 Chapter 8 SNMP Management: RMON

28. Notes Host Top N Group Example Network Management: Principles and Practice © Mani Subramanian 2011 28 Chapter 8 SNMP Management: RMON

29. Matrix Group Stores statistics on conversations between pairs of hosts. An entry is created for each conversation that the probe detects. It creates new entries based on information received in good packets. Contains three tables: –matrixControlTable: controls the information to be gathered. –matrixSDTable: keeps track of the source to destination conversations. –matrixDSTable: keeps track of the destination to source conversations. Network Management: Principles and Practice © Mani Subramanian 2011 29 Chapter 8 SNMP Management: RMON

30. Matrix Group (Cont.) MatrixSDEntry ::= SEQUENCE { matrixSDSourceAddress OCTET STRING, matrixSDDestAddress OCTET STRING, matrixSDIndex Integer32, matrixSDPkts Counter32, matrixSDOctets Counter32, matrixSDErrors Counter32 } matrixSDPkts → The number of packets transmitted from the source address (SA) to the destination address (DA) including bad packets. matrixSDOctets → The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from SA to DA. matrixSDErrors → The number of bad packets transmitted from SA to DA. Network Management: Principles and Practice © Mani Subramanian 2011 30 Chapter 8 SNMP Management: RMON

31. Filter Group Notes Filter group used to capture packets defined by logical expressions Channel is a stream of data captured based on a logical expression Filter table allows packets to be filtered with an arbitrary filter expression Set of filters are associated with each channel A row in the channel table associated with multiple rows in the filter table Network Management: Principles and Practice © Mani Subramanian 2011 31 Chapter 8 SNMP Management: RMON

32. Filter Group (Cont.) Each filter associated with a channel is OR'ed with the others. Within a filter, any bits checked in the data and status are AND'ed with respect to other bits in the same filter. The NotMask allows for checking for inequality. The channelAcceptType object allows for inversion of the whole equation. Network Management: Principles and Practice © Mani Subramanian 2011 32 Chapter 8 SNMP Management: RMON

33. Filter Table FilterEntry ::= SEQUENCE { filterIndex Integer32, filterChannelIndex Integer32, filterPktDataOffset Integer32, filterPktData OCTET STRING, filterPktDataMask OCTET STRING, filterPktDataNotMask OCTET STRING, filterPktStatus Integer32, filterPktStatusMask Integer32, filterPktStatusNotMask Integer32, filterOwner OwnerString, filterStatus EntryStatus } filterPktDataOffset → Offset from the beginning of each packet where a match of packet data will be attempted filterPktData → Data that is to be matched with the input packet filterPktDataMask → The mask that is applied to the match process. if the associated filterPktData object is longer than this mask, this mask is conceptually extended with '1' bits. filterPktDataNotMask → The inversion mask that is applied to the match process. if the associated filterPktData object is longer than this mask, this mask is conceptually extended with '0' bits. Network Management: Principles and Practice © Mani Subramanian 2011 33 Chapter 8 SNMP Management: RMON

34. Channel Table ChannelEntry ::= SEQUENCE { channelIndex Integer32, channelIfIndex Integer32, channelAcceptType INTEGER, channelDataControl INTEGER, channelTurnOnEventIndex Integer32, channelTurnOffEventIndex Integer32, channelEventIndex Integer32, channelEventStatus INTEGER, channelMatches Counter32, channelDescription DisplayString, channelOwner OwnerString, channelStatus EntryStatus } channelAcceptType → acceptMatched(1), or acceptFailed(2) [i.e., packets will be accepted if they fail to match associated filters] channelDataControl → on(1) or off(2) channelTurnOnEventIndex → event configured to turn the associated channelDataControl on when the event is generated channelEventIndex → event to be generated when the associated channelDataControl is on and a packet is matched channelEventStatus → eventReady(1), eventFired(2), or eventAlwaysReady(3) channelMatches → number of times this channel has matched a packet (this is updated even when channelDataControl = off). Network Management: Principles and Practice © Mani Subramanian 2011 34 Chapter 8 SNMP Management: RMON

35. Packet Capture Group Capture Buffer Table (one entry per channel) Filter Table (many for each channel) Channel Table Notes Packet Capture Group requires implementation of the Filter Group. Packet capture group is a post-filter group. Buffer control table used to select channels. Captured data stored in the capture buffer table. Network Management: Principles and Practice © Mani Subramanian 2011 35 Chapter 8 SNMP Management: RMON

36. Buffer Control Table BufferControlEntry ::= SEQUENCE { bufferControlIndex Integer32, bufferControlChannelIndex Integer32, bufferControlFullStatus INTEGER, bufferControlFullAction INTEGER, bufferControlCaptureSliceSize Integer32, bufferControlDownloadSliceSize Integer32, bufferControlDownloadOffset Integer32, bufferControlMaxOctetsRequested Integer32, bufferControlMaxOctetsGranted Integer32, bufferControlCapturedPackets Integer32, bufferControlTurnOnTime TimeTicks, bufferControlOwner OwnerString, bufferControlStatus EntryStatus } bufferControlFullStatus → spaceAvailable(1) or full(2) bufferControlFullAction → lockWhenFull(1), or wrapWhenFull(2) [i.e., FIFO] Network Management: Principles and Practice © Mani Subramanian 2011 36 Chapter 8 SNMP Management: RMON

37. Event Group Controls the generation and notification of events from this device. Each entry in the eventTable describes the parameters of the event that can be triggered. Each event entry is fired by an associated condition located elsewhere in the MIB. An event entry may also be associated with a function elsewhere in the MIB that will be executed when the event is generated. Both rising and falling alarms can be specified in the eventTable associated with the group. In addition to transmitting events, the system optionally maintains a log in logTable. Network Management: Principles and Practice © Mani Subramanian 2011 37 Chapter 8 SNMP Management: RMON

38. Notes RMON TR Extension Groups (RFC 1513) Two statistics groups and associated history groups: MAC layer (Statistics group) collects Token-Ring (TR) parameters. Promiscuous Statistics group collects packets promiscuously on sizes and types of packets. Three groups associated with the stations. Source Routing group gathers statistics from source routing information. Network Management: Principles and Practice © Mani Subramanian 2011 38 Chapter 8 SNMP Management: RMON

39. Notes RMON2 (RFC 4502) Applicable to Layers 3 and above Functions similar to RMON1 Enhancement to RMON1 Defined conformance and compliance Network Management: Principles and Practice © Mani Subramanian 2011 39 Chapter 8 SNMP Management: RMON

40. RMON2 MIB Notes Network Management: Principles and Practice © Mani Subramanian 2011 40 Chapter 8 SNMP Management: RMON

41. Network-Layer visibility In RMON1, an RMON probe can: monitor traffic on LANs to which it is attached. capture all of the MAC-level frames. read source and destination MAC addresses (SA and DA). provide info about MAC traffic between hosts. If a router is attached to a LAN, an RMON1 probe can only monitor the total traffic to/from the router → Can’t determine the ultimate SA or DA. RMON2 probe is capable of reading the header of network-layer protocol (e.g., IP) → Can analyze traffic passing through a router and determine the ultimate SA and DA. → Can provide more info about the traffic loads on the network (e.g., for troubleshooting) → optimize traffic flow and improve performance. Network Management: Principles and Practice © Mani Subramanian 2011 41 Chapter 8 SNMP Management: RMON

42. Application-Level visibility RMON2 probes are capable of seeing above the IP layer by reading higher-level headers (e.g., TCP). In RMON2, a NM application can generate charts and graphs depicting traffic percentage by protocols or by applications. Usage of the Term “Application Level” (RFC 2021) In this MIB, the term Application Level is used to describe a class of protocols or a capability. This does not typically mean a protocol that is an OSI Layer 7 protocol. Rather, it is used to identify a class of protocols that is not limited to MAC-layer and network- layer protocols, but can also include transport, session, presentation, and application-layer protocols. Network Management: Principles and Practice © Mani Subramanian 2011 42 Chapter 8 SNMP Management: RMON

43. New Functional Features in RMON2 Indexing with External Objects: In RMON1, a data table can have many indices. The first index object just duplicates an index value from the index object for the control table. In RMON2, the data table uses the index object of the control table (i.e., an external object) as one of its indices → the data table has one less columnar object (i.e., the previously duplicate index). RMON2 uses RowStatus (defined in SNMPv2) instead of EntryStatus used in RMON1 to define status objects. Time Filter Indexing: It is desirable to have the probe return values only for those objects whose values have changed since the last poll → Use of TimeFilter. Network Management: Principles and Practice © Mani Subramanian 2011 43 Chapter 8 SNMP Management: RMON

44. Textual Convention: TimeFilter and LastCreateTime Timefilter used to download only those rows that changed after a particular time. Notes LastCreateTime tracks change of data with the changes in control in the control tables: Used for polling applications to determine that an entry has been deleted and re-created between polls, causing an otherwise undetectable discontinuity in the data Network Management: Principles and Practice © Mani Subramanian 2011 44 Chapter 8 SNMP Management: RMON

45. Protocol Directory Group (protocolDir) A central point for storing information about types of protocols. Lists the inventory of protocols the probe has the capability of monitoring. Allows the addition, deletion, and configuration of entries in this list. Includes a protocolDirTable that: has one entry for each protocol for which the probe can decode and count PDUs. covers MAC-, network-, and higher-layer protocols. Includes protocolDirLastChange, which contains the time of the last table update. Network Management: Principles and Practice © Mani Subramanian 2011 45 Chapter 8 SNMP Management: RMON

46. Protocol Directory Table (protocolDirTable) ProtocolDirEntry ::= SEQUENCE { protocolDirID OCTET STRING, protocolDirParameters OCTET STRING, protocolDirLocalIndex Integer32, protocolDirDescr DisplayString, protocolDirType BITS, protocolDirAddressMapConfig INTEGER, protocolDirHostConfig INTEGER, protocolDirMatrixConfig INTEGER, protocolDirOwner OwnerString, protocolDirStatus RowStatus } protocolDirID: contains a unique octet string for a specific protocol. It is arranged in a tree-structured hierarchy. The root of this tree is the identifier of the MAC-level protocol. Examples: ether2: [4.0.0.0.1], ether2.ip.udp.snmp: [16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161] protocolDirParameters: A set of parameters for the associated protocolDirID (see RFC 3395) Network Management: Principles and Practice © Mani Subramanian 2011 46 Chapter 8 SNMP Management: RMON provides number of bytes used for protocol ID

47. Protocol Distribution Group (protocolDist) Collects the relative amounts of octets and packets for the different protocols detected on a network segment. Consists of 2 tables: protocolDistControlTable: Controls the setup of protocol type distribution statistics tables. Each row refers to a unique interface for this probe, and controls a number of rows of protocolDistStatsTable, one for each protocol recognized on that interface. protocolDistStatsTable: includes one row for each protocol in protocolDirTable for which at least one packet has been seen. It includes 2 columnar objects: - protocolDistStatsPkts: Number of packets without errors received of this protocol type. - protocolDistStatsOctets: Number of octets in packets received of this protocol type since it was added to the protocolDistStatsTable. Network Management: Principles and Practice © Mani Subramanian 2011 47 Chapter 8 SNMP Management: RMON

48. Address Map Group (addressMap) Lists MAC address to network address bindings discovered by the probe and what interface they were last seen on. Useful in node discovery and network topology applications. Consists of 3 scalar objects and 2 tables: addressMapInserts: Number of times an address mapping entry has been inserted into the data table. addressMapDeletes: Number of times an address mapping entry has been deleted from the data table. → Table size = addressMapInserts - addressMapDeletes addressMapMaxDesiredEntries: Desired maximum number of entries in the addressMapTable. (-1 means “any number of entries”.) addressMapControlTable addressMapTable Network Management: Principles and Practice © Mani Subramanian 2011 48 Chapter 8 SNMP Management: RMON

49. Address Map Tables addressMapControlTable: controls the collection of network layer address to physical address to interface mappings. Each entry in this table enables the discovery of addresses on a new interface and the placement of address mappings into the central addressMapTable. addressMapTable: A table of network layer address to physical address to interface mappings. The probe will add entries to this table based on the source MAC and network addresses seen in packets without MAC-level errors. Each row stores information about: - addressMapNetworkAddress - addressMapSource : I nterface or port on which the associated network address was most recently seen. - addressMapPhysicalAddress: Last source physical address on which the associated network address was seen. Network Management: Principles and Practice © Mani Subramanian 2011 49 Chapter 8 SNMP Management: RMON

50. Network Layer Host Group (n1Host) Counts the amount of traffic sent from and to each network address discovered by the probe. Similar to the RMON1 host group, except that n1Host gathers statistics based on network-layer address. Consists of 2 tables: h1HostControlTable: A list of higher layer (i.e. non-MAC) host table control entries. A separate count of inserts, deletes, and MaxDesiredEntries is kept for n1HostTable and a1HostTable. n1HostTable: A collection of statistics for a particular network layer address that has been discovered on an interface of this device. Each row stores information about: - n1HostAddress - n1HostInPkts & n1HostOutPkts - n1HostInOctets & n1HostOutOctets Network Management: Principles and Practice © Mani Subramanian 2011 50 Chapter 8 SNMP Management: RMON

51. Network Layer Matrix Group (n1Matrix) Counts the amount of traffic sent between each pair of network addresses discovered by the probe. Similar to the RMON1 matrix group and hostTopN group, except that n1Matrix gathers statistics based on network-layer address. Consists of 5 tables: h1MatrixControlTable n1MatrixSDTable n1MatrixDSTable n1MatrixTopNControlTable n1MatrixTopNTable Network Management: Principles and Practice © Mani Subramanian 2011 51 Chapter 8 SNMP Management: RMON

52. Network Layer Source/Dest. Statistics h1MatrixControlTable: A list of higher layer (i.e. non-MAC) matrix control entries. A separate count of inserts, deletes, and MaxDesiredEntries is kept for n1MatrixTable and a1MatrixTable. n1MatrixSDTable: A list of traffic matrix entries which collect statistics for conversations between two network-level addresses. It is indexed by SA then DA. Each row stores information about: - n1MatrixSDPkts - n1MatrixSDOctets n1MatrixDSTable: contains the same info as n1MatrixSDTable, but it is indexed by DA then SA. Network Management: Principles and Practice © Mani Subramanian 2011 52 Chapter 8 SNMP Management: RMON

53. Network Layer TopN Statistics In RMON2 TopN statistics table, the ranking is of the traffic between pairs of hosts. (In RMON1, it is based on individual hosts.) n1MatrixTopNControlTable: A set of parameters that control the creation of a report of the top N matrix entries according to a selected metric. n1MatrixTopNTable: A set of statistics for those network layer matrix entries that have counted the highest number of octets or packets. Each row stores information about: - n1MatrixTopNProtocolDirLocalIndex - n1MatrixTopNSourceAddress - n1MatrixTopNDestAddress - n1MatrixTopNPktRate - n1MatrixTopNReversePktRate - n1MatrixTopNOctetRate - n1MatrixTopNReverseOctetRate Network Management: Principles and Practice © Mani Subramanian 2011 53 Chapter 8 SNMP Management: RMON

54. Application Layer Host Group (a1Host) The application layer host, matrix, and matrixTopN functions report on protocol usage at the network layer or higher. a1Host group counts the amount of traffic, by protocol, sent from and to each network address discovered by the probe. Similar to the RMON1 host group, except that a1Host gathers statistics based on application-layer address. h1HostControlTable also controls a1HostTable. a1HostTable: A collection of statistics for a particular protocol from a particular network address that has been discovered on an interface of this device (one Index is the external object: n1HostAddress). Each row stores information about: - a1HostInPkts & a1HostOutPkts - a1HostInOctets & a1HostOutOctets Network Management: Principles and Practice © Mani Subramanian 2011 54 Chapter 8 SNMP Management: RMON

55. Application Layer Matrix Group (a1Matrix) Counts the amount of traffic, by protocol, sent between each pair of network addresses discovered by the probe. Similar to the RMON1 matrix group and hostTopN group, except that a1Matrix gathers statistics based on application-layer address. h1MatrixControlTable also controls a1MatrixSDTable and a1MatrixDSTable. Consists of 4 tables: n1MatrixSDTable a1MatrixDSTable a1MatrixTopNControlTable a1MatrixTopNTable Network Management: Principles and Practice © Mani Subramanian 2011 55 Chapter 8 SNMP Management: RMON

56. Application Layer Statistics Application Layer Source/Dest. Statistics: h1MatrixControlTable: A list of higher layer (i.e. non- MAC) matrix control entries. A separate count of inserts, deletes, and MaxDesiredEntries is kept for n1MatrixTable and a1MatrixTable. n1MatrixSDTable: A list of traffic matrix entries which collect statistics for conversations between two application-level addresses. The indexing of this table involves 6 index objects from 3 different tables. It is indexed by SA then DA. Each row stores information about: - a1MatrixSDPkts - a1MatrixSDOctets n1MatrixDSTable: contains the same info as n1MatrixSDTable, but it is indexed by DA then SA. Application Layer TopN Statistics: a1MatrixTopNControlTable: similar to network-layer TopN control table. a1MatrixTopNTable: similar to network-layer TopN control table. Network Management: Principles and Practice © Mani Subramanian 2011 56 Chapter 8 SNMP Management: RMON

57. User History Collection Group (usrHistory) Combines mechanisms seen in the alarm and history groups to provide user-specified history collection, utilizing 2 additional control tables and 1 additional data table. This function has traditionally been done by NMS applications, via periodic polling. The usrHistory group allows this task to be offloaded to an RMON probe. Data (an INTEGER based object) is collected in the same manner as any history data table (e.g. etherHistoryTable) except that the user specifies the MIB instances to be collected. Objects are collected in bucket-groups. usrHistoryControlTable is a one-dimensional read-create table. Each row configures a collection of user history buckets, much the same as a historyControlEntry, except that the creation of a row in this table will cause one or more associated instances in the usrHistoryObjectTable to be created. usrHistoryObjectTable is a 2-d read-write table. Each row configures a single MIB instance to be collected. All rows with the same major index constitute a bucket-group. usrHistoryTable is a 3-d read-only table containing the data of associated usrHistoryControlEntries. Each entry represents the value of a single MIB instance during a specific sampling interval (or the rate of change during the interval). Network Management: Principles and Practice © Mani Subramanian 2011 57 Chapter 8 SNMP Management: RMON

58. Probe Configuration Group (ProbeConfig) This group controls the configuration of various operating parameters of the probe. Enhances interoperability among RMON probes and managers by defining a standard set of configuration parameters for probes → One vendor’s RMON application is able to configure remotely another vendor’s RMON probe. Includes a set of scalar objects: probeCapabilities: indicates which RMON groups are supported on at least one interface by this probe. probeSoftwareRev: software revision of this device. probeHardwareRev: hardware revision of this device. probeDateTime: Probe's current date and time. probeResetControl: takes on the values running(1), warmBoot(2), and coldBoot(3). probeDownloadFile: The name of the file that contains the boot image to be downloaded from the TFTP server. probeDownloadTFTPServer: The IP address of the TFTP server that contains the boot image to load. probeDownloadAction: takes on the values notDownloading(1), downloadToPROM(2), and downloadToRAM(3). probeDownloadStatus: The status of the last download procedure, if any. E.g., downloadSuccess(1), … downloadTftpFileNotFound(7), … Network Management: Principles and Practice © Mani Subramanian 2011 58 Chapter 8 SNMP Management: RMON

59. Probe Configuration Group (ProbeConfig) Includes 4 tables: serialConfigTable: A table of serial interface configuration entries. netConfigTable: Each row stores a set of configuration parameters for a particular network interface on this device. trapDestTable: defines the destination addresses for traps generated from the device. This table maps a community to one or more trap destination entries. serialConnectionTable: stores the parameters for initiation of a connection over the serial interface. Network Management: Principles and Practice © Mani Subramanian 2011 59 Chapter 8 SNMP Management: RMON

60. Extensions to the RMON 1 MIB for RMON 2 devices These extensions include: The standard LastCreateTime Textual Convention for all control tables, and An augmentation of the filter entry that provides variable-length offsets into packets. Example: etherStats2Entry OBJECT-TYPE SYNTAX EtherStats2Entry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains the RMON-2 augmentations to RMON-1." AUGMENTS { etherStatsEntry } ::= { etherStats2Table 1 } EtherStats2Entry ::= SEQUENCE { etherStatsDroppedFrames Counter32, etherStatsCreateTime LastCreateTime } Network Management: Principles and Practice © Mani Subramanian 2011 60 Chapter 8 SNMP Management: RMON

61. Notes A Case Study A study at Georgia Tech on Internet traffic growth Objectives Analyze traffic growth and trend Analyze traffic patterns Network comprising Ethernet and FDDI LANs Tools used to gather data & RMON stats: HP Netmetrix protocol analyzer for Ethernet Special high-speed TCP dump tool for FDDI LAN RMON groups utilized Host top-n Matrix group Filter group Packet capture group (for application level protocols) Network Management: Principles and Practice © Mani Subramanian 2011 61 Chapter 8 SNMP Management: RMON

62. Case Study Results Network Management: Principles and Practice © Mani Subramanian 2011 62 Chapter 8 SNMP Management: RMON