RMON2

1. RMON2

2. 10.1 Overview • RMON MIB specification to include monitoring of protocol traffic above the MAC level • An RMON probe can monitor traffic on the basis of network-layer protocols and addresses, including the Internet Protocol (IP) • Because an RMON probe can decode and monitor application-level traffic, such as email, file transfer, and WWW protocols, the probe can record traffic to and from hosts for particular applications.

3. 10.1.1 Network-Layer Visibility • RMON probe with RMON1 can monitor all of the traffic on the LANs, or can capture all of the MAC-level frames and read the MAC-level source and destination addresses in those frames. • But, no way of determining the ultimate source of incoming traffic arriving via the router or the ultimate destination of outgoing traffic leaving via the router. • With RMON2, the RMON probe has the capability of seeing above the MAC layer by reading the header of the enclosed network-layer protocol, which is typically IP. • analyzing traffic passing through the router to determine the ultimate source and destination.

4. Network-Layer Visibility (cont’d) • Answering a number of new questions by a network manager • If there is excessive load on the LAN due to incoming router traffic, what networks or hosts account for the bulk of that incoming traffic ? • If a router is overload because of high amounts of outgoing traffic, what local hosts account for the bulk of that outgoing traffic, and to what destination networks or hosts in that traffic directed ? • If there is a high load of pass-through traffic (arriving via one router and departing via another router), what networks or hosts are responsible for the bulk of this traffic ? • The network manager may be able to take steps to contain traffic loads and improve performance. • optimizing traffic flow

5. 10.1.2 Application-Level Visibility • RMON 2 probe is capable of seeing above the IP layer by reading the enclosed higher-level headers such as TCP and viewing the headers at the applications protocol level. • allowing the network manager to monitor traffic in great detail • With RMON2, a network application can be implemented that will generate charts and graphs depicting traffic percentage by protocols or by applications.

6. 10.1.13 The RMON2 MIB rmon (mib-2, 16) statistics (1) protocolDir (11) history (2) ProtocolDist (12) alarm (3) addressMap(13) host (4) nlHost (14) hostTopN (5) nlMatrix (15) alHost (16) matrix (6) alMatrix (17) filter (7) usrHistory (18) capture (8) probeConfig (19) event (9) rmonConformance (20) tokenRing (10) RMON2 RMON1

7. The RMON2 MIB • The new mib group defined in RMON2. • protocol directory (protocolDir) : master directory of all of the protocols that the probe can interpret • protocol distribution (protocolDist) : aggregate statistics on the amount of traffic generated by each protocol, per LAN segment • address map (addressMap) : matches each network address to a specific MAC address and port on an attached device and physical address on this subnetwork • network-layer host (nlHost) : statistics on the amount traffic into and out of hosts on the basis of network-layer address • network-layer matrix (nlMatrix) : statistics on the amount of traffic between pairs of hosts on the basis of network-layer address

8. The RMON2 MIB (cont’d) • application-layer host (alHost) : statistics on the amount of traffic into and out of hosts on the basis of application • application-layer matrix (alMatrix) : statistics on the amount of traffic between pairs of hosts on the basis of application-layer address • user history collection (usrHistory) : periodically samples user-specified variables and logs that data based on user-defined parameters • probe configuration (probeConfig) : defines standard configuration parameters for RMON probes

9. 10.1.4 New Functional Features in RMON2 • Enhancing the power and flexibility of RMON • the use of index objects that are not part of the table objects index, and the use of time filter indexing • Indexing with external Objects • SMI for SNMPv2 explicitly states that it is possible to use an object that is not part of a conceptual table as an index for that table. • in that case, the DESCRIPTION clause for the conceptual row must include a textual explanation of how such objects are to be used in uniquely identifying a conceptual row instance. • In Figure 8.2, the data table is in indexed by rm1DataControlIndex and then rm1DataIndex. • The value of rmlDataControlIndex is the same as the value of rmlControlIndex in rmlControlTable that defines the control row for this data entry. • Seeing an example of this type of structure in Figure 8.8, which showing the layout of the RMON1 history table

10. New Functional Features in RMON2 (cont’d) • Indexing with external Objects (cont’d) • Figure 10.2 shows the same type of control table and date table definition in the RMON2 style. • Suppose that we are interested in the set of data rows controlled by the second control row and that we are further interested in the 89th member, or row, of that set. • The instance of the value of that row would be named rm2DataValue.2.89 • In this case, the index value “2” refers to rm2ControlIndex. • Another difference found in RMON2 is that status objects are specified as having syntax RowStatus rather than EntryStatus • RowStatus provides a more elaborate method for adding and removing rows than that supported byEntryStatus.

11. New Functional Features in RMON2 (cont’d) • Time Filter Indexing • A common function of a network management application is periodically to poll all probes for values of objects maintained at the probe. • For the sake of efficiency, it is desirable to have the probe return values only for those objects whose values have changed since the last poll • no direct way in SNMP or SNMP2 to achieve this function • RMON2 has an innovative means of achieving above functionality in the MIB definition TimeFilter :: = TEXTUAL – CONVENTION STATUS CURRENT DESCRIPTION “…………” SYNTAX TimeTicks

12. 10.2 Protocol Directory Group (protocolDir) • addresses a key difficulty in the remote monitoring of protocol traffic above the MAC layer. • On any particular network, many different protocols may be running. • The purpose of the protocol directory group • providing a single central point for storing information about types of protocols • The protocol directory group provides a way for an RMON2 manager to learn which protocols a particular RMON2 probe interprets. • This information is especially important when the manager and probe are from different vendors

13. Protocol Directory Group (cont’d) • RMON2 protocol directory group (Figure 10.5) • including a protocol directory table, with one entry for each protocol for which the probe can decode and count PDUs. • The table covers MAC-, network-, and higher-layer protocols • DirLastChange : containing the time of the last table update

14. Protocol Directory Group (cont’d)

15. 10.2.1 Protocol Identification • Protocol Identifier • ProtocolDirID object contains a unique octet string for a specific protocol • Octet string identifies for protocols are arranged in a tree-structured hierarchy, similar to the hierarchy of MIB objects ether 2 = 1 [ 0.0.0.1 ] llc = 2 [ 0.0.0.2 ] snap = 3 [ 0.0.0.3 ] vsnap = 4 [ 0.0.0.4 ] ianaAssigned = 5 [ 0.0.0.5 ] • The identifier for IP running over Ethernet :ether2.ip • UDP running over IP on an Ethernet LAN : ether2.ip.udp • for SNMP,ether2.ip.udp.snmp

16. Protocol Identification (cont’d) • Protocol Identifier (cont’d) • Ethernet MAC protocol [0.0.a.b], where a and b contain the 16-bit value in the Type field of an Ethernet MAC protocol • In case of IP, [ 0.0.8.0 ] • IP PDU includes eight-bit Protocol field that identifies that user of IP : [ 0.0.0.a ] • The protocol identifier for UDP running over IP is [ 0.0.0.17] • UDP PDU format includes a 16-bit Port field to identify a UDP user. • In case of SNMP, [ 0.0.0.0.161] • So, protocolDirID that uniquely identifies SNMP running over UDP/IP on Ethernet: 16.0.0.0.10.0.0.8.0.0.0.0.17.0.0.0.161 16 octets

17. Protocol Identification (cont’d) • Protocol Identifier (cont’d) • Capability of the probe in above example - interpreting all incoming Ethernet frames - looking past the Ethernet header and trailer and interpreting the encapsulated IP datagram - looking past the IP header and interpreting the encapsulated UDP segment - looking past the UDP header and interpreting the encapsulated SNMP PDU

18. Protocol Identification (cont’d) • Protocol Parameters • 16.0.0.0.10.0.0.8.0.0.0.0.17.0.0.0.161.4.0.1.0.0 This indexes an entry in protocolDirTable referring to the protocol SNMP running over UDP/IP/Ethernet, with fragments counted correctly for IP and above • A new protocol descriptor macro has been specified. The macro is defined using a simple Backus-Naur Form (BNF) syntax rather than ASN.1 • See Page 292 • See Figure 10.7

19. 10.2.2 Protocol Directory Table • protocolDirLocalIndex : an arbitrary unique index number associated with this entry • protocolDirDesc : a textual description object • prtocolDirType : extensible (0), addressRecognitionCapable (1) • protocolDirAddressMapConfig : notSupported (1), supportedOff (2), supportedOn (3) • protocolDirHostConfig : notSupported (1), supportedOff (2), supportedOn (3) • protocolDirMatrixConfig : notSupported (1), supportedOff (2), supportedOn (3) • ptotocoDirOwner • protocolDirStatus

20. Protocol Distribution Group • summarizes how many octets and packets have been sent from each of the protocols supported. • protocolDistControlTable : controlling collection of basis statistics for all supported protocols • refers to a unique network interface for this probe and controls a number of rows of protocolDistStatsTable • protocolDistStatsTable : recording the data • It is indexed by protocolDistControlIndex and by protocolDirLocalIndex, which uniquely identifies a particular protocol

21. Protocol Distribution Group (cont’d)

22. 10.4 Address Map Group • matches each network address to a specific MAC-level address and therefore to a specific port on the network device. • helpful in node discovery and network topology applications for pinpointing the specific paths of network traffic • has three scalar objects, a control table, a data table • addressMapInserts • addressMapDeletes • addressMapMaxDesiredEntries • addressControlTable • addressMapTable • Current size of the data table = addressMapInserts - addressMapDeletes

23. Address Map Group (cont’d)

24. Address Map Group (cont’d) • A single ‘central’ data table that contains entries that provide the mapping between network-layer (typically IP) addresses and MAC addresses. • addressMapTable will collect address mappings based on source MAC and network addresses seen in error-free MAC frames • The table will create entries for all protocols in the protocol directory table whose value of protocolDirAddressMapConfig is equal to supportedOn (3) • Given a network address for a particular protocol observed on a particular amount of time, the MAC address (only one entry in the table) for any specific network address.

25. 10.5 RMON2 Host Groups • Two RMON2 groups deal with the collection of statistics on a host basis: the network layer host group and the application analysis group • Both of these groups contain a data table is controlled by a control table in the network-layer host group

26. 10.5.1 Network-layer Host Group • enables users to decode packets based on their network-layer address • letting the network manager look beyond a router to the connected hosts • collecting similar statistics to those collected in the RMON1 host group. (Fig. 8.9) ( based on MAC address)

27. Network-layer Host Group (cont’d)

28. Network-layer Host Group (cont’d) • The nlHostTable will create entries for all network-layer protocols in the protocol directory table whose value of protocolDirHostConfig is equal to supportedOn(3) • The probe adds entries to this table for all addresses seen as the source or destination address in all packets with no MAC errors. • After a new row is defined in nlHostControlTable, the monitor begins to learn network-layer addresses on the corresponding interface. • Each time a new network-layer address is discovered on that interface, a row is added to hostTable, and the value of nlHostControlNlInserts is incremented by one

29. Network-layer Host Group (cont’d) • The nlHostTable is indexed by four objects: nlHostControlIndex, which defines the interface; nlHostTimeMark, a time filter; protocolDirLocalIndex, the identity of the protocol; and nlHostAddress, the network address. • Given a network address for a particular protocol observed on a particular interface within a particular amount of time, the traffic statistics for that address can be read.

30. 10.5.2 Application-layer Host Group • The nlHostControlTable also controls alHostTable in the application-layer host group. • There is one entry in alHostTable for each application-level protocol discovered at each known network-layer address. • The alHostTable will create entries for all application-level protocols in the protocol directory table whose value of protocolDirAlHostConfig is equal to supportedOn (3). • The probe addes entries to this table for all addresses seen as the source or destination address in all packets with no MAC errors. • For example, the user could learn of the amount of traffic generated or received by Lotus Notes or MS Mail, a given host.

31. Application-layer Host Group (cont’d)

32. 10.6 RMON2 Matrix Groups • RMON1 matrix groups gather statistics based on MAC addresses whereas the RMON matrix groups gather statistics based on network-layer address and on application-level protocol. • network-layer matrix ( nlMatrix ) • application-layer matrix ( alMatrix )

33. 10.6.1 Network-Layer Matrix Group • consists of five tables : two control tables and three data tables.

34. Network-Layer Matrix Group (cont’d) • Network-layer source/destination statistics • The nlMatrixControlTable • The nlMatrixSDTable is used to store statistics on traffic from a particular source network-layer address to a number of destinations. • The nlMatrixSDTable will create entries for all application-level protocols in the protocol directory table whose value of protocolDirNlMatrixConfig is equal to supportedOn (3). • Network-layer TopN statistics • In RMON1, the HostTopN gorup maintains statistics that rank individual hosts on one subnetwork based on some parameter. • In case of RMON2 TopN statistics table, the ranking is of the traffic between pairs of hosts based on some parameter. • nlMatrixTopNControlTable • nlMatrixTopNTable

35. Network-Layer Matrix Group (cont’d)

36. Network-Layer Matrix Group (cont’d) • Unlike RMON1, RMON2 TopN tables automatically retriggers when the sort completes. In this way, the stored report us updated every TopNDuration seconds automatically. • A network management system can determine whether a new report is available yet by polling the TopNGeneratedReports object.

37. Application-Layer Matrix Group • One control tables and three data tables • two data tables : dealing with the collection of matrix statistics • other data tables : dealing with the collection of topN statistics • Application-layer source/destination statistics • alMatrixSDPkts.1.783495.18.4.128.2.6..6.4.128.2.6.7.34 • Application-layer TopN Statistics

38. Application-Layer Matrix Group (cont’d)

39. Application-Layer Matrix Group (cont’d)

40. 10.7 User History Collection Group • periodically polls particular statistics and variables and then logs that data based on user-defined parameters • Network manager can configure history studies of any counter in the system, such as a specific history on a particular file server or router-to-router connection. • This group consists of a three-level hierarchy of tables (Figure 10.15) • usrHistoryControlTable : specifying the details of the sampling function • usrHistoryObjectTable : each row of usrHistoryObjectTable refers to a single mib object instance. • usrHistoryTable : presenting the value of a single mib object instance during a specific sampling interval

41. User History Collection Group

42. 10.8 Probe Configuration Group • is designed to enhance interoperability among RMON probes and managers by defining a standard set of configuration parameters for probes. • it makes easier for one vendor’s RMON application to be able to configure remotely another vendor’s RMON

43. Probe Configuration Group (cont’d)

44. Probe Configuration Group (cont’d) • Control Strings • Textual convention for use by several of the tables in the probe configuration group ControlString :: = DisplayString • used to communicate with a modem or serial data switch • represented by two-character sequences beginning with ^ character • ^s, ^c, ^t, ^w, ^!, ^d, ^b • Serial configuration table • Network configuration table • Trap destination table • Serial connection table

45. 10.9 Extensions to RMON1 for RMON Devices • A createTime object is added to all control tables • A dorppedFrames object is added to a number of tables, included as a filter object in all filter definitions • The object filterProtocolDirLocalIndex is added to filterTable See Table 10.2

46. 10.10 Practical Issues • tested on a fast Ethernet (100 Mbps) LAN segment, to which was attached the probe plus two traffic generators, one for TCP segments and one for UDP segments