1 / 82

RMON2

RMON2. RFC2021 Decode packets at layer 3 through 7 of the OSI Model An RMON probe can monitor traffic on the basis of network-layer protocol To look beyond the LAN segment The probe can record traffic to and from host for particular applications Can monitor application-level traffic.

emily-ramsey
Download Presentation

RMON2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RMON2 • RFC2021 • Decode packets at layer 3 through 7 of the OSI Model • An RMON probe can monitor traffic on the basis of network-layer protocol • To look beyond the LAN segment • The probe can record traffic to and from host for particular applications • Can monitor application-level traffic

  2. Network layer Visibility • Network Manager can answer these questions • If there is excessive load on the LAN due to incoming router traffic, what networks or hosts account for the bulk of incoming traffic? • If a router is overloaded because of high amount of outgoing traffic, what networks or hosts account for the bulk of outgoing traffic or to what destination networks or hosts is 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

  3. Application Level Visibility • RMON2 probe is capable of seeing above the IP layer by reading the enclosed higher-level headers such as TCP/UDP and viewing the headers at the application protocol level • This information is useful in controlling load and maintaining performance • NMS can be implemented that will generate charts and graphs depicting traffic percentage by protocols or by applications

  4. RMON MIB (1&2)

  5. RMON2 MIB (1) • protocol directory – a master of directory off all protocols that probe can interpret • protocol distribution – aggregate statistics on the amount of traffic generated by each protocol per LAN segment • address map – match each network address to a specific MAC level address and port on an attached device and the physical address on this subnetwork • network layer host – statistics on the amount of traffic into and out of hosts on the basis of the network-layer address

  6. RMON2 MIB (2) • network-layer matrix – statistics on the amount of traffic between pairs of hosts on the basis of network address • application-layer host - statistics on the amount of traffic into and out of hosts on the basis of application-level address • application-layer matrix - statistics on the amount of traffic between pairs of hosts on the basis of application-level address

  7. RMON2 MIB (3) • User history collection – periodically samples user-specified variables and logs that data based on user-defined parameters • Ex. Collect data on a router-to-router connection • Probe configuration – define standard configuration parameters for RMON probes • To solve interoperability problems

  8. New features in RMON2 (1) • Indexing with external objects • Reduce control index object in data table • To access instance of the data entry in RMON 1 Vs RMON2 • Rm1datavalue.Rm1controlindex.Rm1dataindex • Rm1datavalue.2.89 • 2 – Rm1controlindex / 89 – Rm1dataindex • Rm2datavalue.X.Rm2dataindex • X – the value of index that specifying set of data rows by the Xth row (external object) • Rm2datavalue.2.89 • 2 – external object / 89 – Rm2dataindex

  9. New features in RMON2 (2) • Time filtering Indexing • Typically, a network management app. is periodically to poll all probes for the values of objects • It is desirable to have the probe return values only for those objects whose value have changed since the last poll • No direct way in SNMP, but RMON2 has a mechanism

  10. Example of time filtering

  11. FooTable

  12. EX1. Time filtering (1) • Suppose fooTable has 2 values of index – 1,2 • If no fooTimeMark , a management station can see only two counter • With fooTimeMark, it is possible to request the values of these counter only if they have been updated since a given time

  13. EX1. Time filtering (2) • For example, current value of • The counter associated with fooIndex = 1 is 5 and most recently updated at time 6 • The counter associated with fooIndex=2 is 9 and most recently updated at time 8 • Then, at time 10, a manager issues the request • GetRequest(fooCounts.7.1, fooCounts.7.2) • To get the value updated since time 7 • The agent will response fooCounts.7.2=9

  14. EX2. Time Filtering (1)

  15. EX2. Time Filtering (2) • Assume that basic row 1 (fooIndex=1) was updated as follows:

  16. EX2. Time Filtering (3) • Assume that basic row 2 (fooIndex=2) was updated as follows:

  17. EX2. Time Filtering (4) • A manager station polls a probe every 15 seconds (clock nms records time in hundredths of second) 1 At nms=1000, the manager does the baseline poll to get everything since the last agent restart (Timefilter =0) GetRequest (sysUpTime.0,fooCounts.0.1,fooCount.0.2) Response(sysUpTime.0=600,fooCounts.0.1=1,fooCount.0.2=0) 2 At nms=2500 (15 second later), the manager get an update on all changes since the last report (agent time=600) GetRequest (sysUpTime.0, fooCounts.600.1, fooCount.600.2) Response(sysUpTime.0=2100,fooCounts.600.1=2,fooCount.600.2=2)

  18. EX2. Time Filtering (5) The agent received the request at a local time of 2100 ; a counter 1 was incremented at time 900 counter 2 was incremented at 1100 and 1400 3 At nms=4000, the manager get an update on all changes since the last report (agent time=2100) GetRequest (sysUpTime.0, fooCounts.2100.1, fooCount.2100.2) Response(sysUpTime.0=3600,fooCounts.2100.1=3) A counter 1 was incremented at time 2300 counter 2 has not changed since 2100 , so no value returned

  19. EX2. Time Filtering (6) 4 At nms=5500, the manager get an update on all changes since the last report (agent time=3600) GetRequest (sysUpTime.0, fooCounts.3600.1, fooCount.3600.2) Response(sysUpTime.0=5500,) Neither counter has been updated since time 3600 , so no value returned

  20. Protocol Directory Group • It provides a single central point for storing information about types of protocols • One entry in the table for each protocol for which the probe can decode and count protocol data unit (PDU) • One scalar objects • protocolDirLastChange which contains the time of the last table change • One columnar object (Table) • protocolDirTable • The table covers MAC, network and higher layer protocols

  21. protocolDirTable • Fig 10.5

  22. Protocol identification • protocolDirID object contains a unique octet string for a specific protocol. • Octet string identifiers for protocols are arranged in a tree structured hierarchy. • Each layer is identified by 32 bit value which is encoded as dot decimal format [a.b.c.d] • EX. Ethernet is hexadecimal 1 which is encoded as [0.0.0.1] and referred to symbolically as ether2

  23. Protocol Assignments • Each layer is identified by a 32 bit number (four octets) • For MAC level protocols • ether2 = 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] • Protocol consideration • network layer, use type field of Ethernet frame (IP =0.0.8.0) • transport layer, use protocol field of IP header (UDP = 0.0.0.17) • application layer, use port field of UDP/TCP header (0.0.0.161)

  24. Entry in protocolDirEntry (1) • EX. Identification of SNMP running over UDP/IP on Ethernet • 16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161 • 16 : the number of octets to follow • So, for previous example the probe is capable of • 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

  25. Entry in protocolDirEntry (2) • A separate entry is needed for each protocol that the probe can interpret and count • Then the four entries are needed in protocolDirEntry and the protocolDirID values would be • Ether2 (4.0.0.0.1) • Ether2.ip (8.0.0.1.0.0.8.0) • Ether2.ip.udp (12.0.0.0.1.0.0.8.0.0.0.0.17) • Ether2.ip.udp.snmp (16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161)

  26. Format of index values for protocolDirTable

  27. Protocol parameter (1) • The second index object for protocolDirTable is protocolDirParameters • This object instance contains information about the probe’s capability with the respect to a particular protocol • The value is structured as a one-octet count field followed by a set of N-octet parameters, one for each protocol layer in protocolDirID • Each bit in the parameter octet is encoded separately to define a particular capability

  28. Protocol parameter (2) • 2 LSB are reserved for all protocols • CountFragment (bit0) : Higher-layer protocols encapsulated within this protocol will be counted correctly even if this protocol fragments the upper-layer PDUs into multiple fragments • tracksSessions (bit1) :Correctly attributes all packets of a port-mapped protocol, that is a protocol start session on a well-known port or socket and then transfer them to dynamically assigned ports or sockets fpr the duration of the session • TFTP (Trivial File Transfer Protocol)

  29. Protocol parameter (3) • SNMP running over UDP/IP/Ethernet withfragments counted correctly for IP or above, the following encoding is for the two objects (protocolDirID, protocolDirParameter) 16.0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.1.0.0

  30. Protocol Directory Table (1) • protocolDirType • extensible(0) if the agent or manager may extend this table by creating entries that are children of this protocol • addressRecognitionCapable(1) indicates that the probe can not only count packets for this protocol but can also recognize source and destination address fields for finer-grained counting

  31. Protocol Directory Table (2) • protocolDirAddressMapConfig • notSupported(1) : if not capable of performing address mapping • If capable then the value may be set to supportedOff(2) or supportedOn(3) • protocolDirHostConfig • It may be set to notsupported(1), supportedOff(2) or supportOn(3) with the respect to the network-layer and application layer host table for this protocol

  32. Protocol Directory Table (3) • protocolDirMatrixConfig • It may be set to notSupported (1) , supportedOff(2), supportedON (3) with the respect to the network-layer and application layer matrix tables for this protocol

  33. Protocol Distribution Group (1) • It summarizes how many octets and packets have been sent from each of the protocols supported • protocolDistControlTable – controls collection of basic statistics for all supported protocols • protocolDistStatsTable – records the data

  34. Protocol Distribution Group (2) • Each row in protocolDistControlTable refers to a unique network interface for this probe and controls a number of rows of protocolDistStatsTable, one for each protocol recognized on that interface

  35. Protocol Distribution Group (3) • protocolDistControlTable consists of • protocolDistControlIndex : an integer that uniquely identifies a row in the protocolDistControlTable • protocolDistControlDatasource : identifies the interface that is th source of the data for this row • protocolDistControlDroppedFrames : total number of received frames for this interface that the probe chose not to count (out of resources) • protocolDistControlCreateTime : the value of sysUptime when this control entry was activated

  36. Protocol Distribution Group (4) • The protocolDistStatsTable includes one row for each protocol in protocolDirTable for which at least one packet has been seen • It is indexed by protocolDistControlIndex and by protocolDirLocalIndex

  37. Protocol Distribution Group (5) • protocolDistStatsTable consists of • protocolDistStatsPkts: the number of packets received for this protocol • protocolDistStatsOctets: the number of octets transmitted to this address since it was added to nlHostTable

  38. Address Map Group (1) • It matches each network address to a specific MAC-level address • It is helpful in node discovery and network topology applications for pinpointing the specific path of the network traffic • 3 scalars objects, one control table (addressMapControlTable) and one data table (addressMapTable)

  39. Address Map Group (1) • 3 scalar objects are • addressMapInserts : the number of times an address-mapping entry has been inserted into the data table • addressMapDeletes: the number of times an address-mapping entry has been deleted into the data table • addressMapMaxDesiredEntries : the desired maximum number of entries in addressMapTable (if this value is set to -1, the probe may create any number of entries in addressMapTable) Data table size = addressMapInserts - addressMapDeletes

  40. Address Map Group (2) • The addressMapControlTable consists of • addressMapControlIndex: an integer that uniquely identifies a row in the addressMapControlTable • addressMapcontrolDatasource : identifies the interface that is the source of the data for this row and that this row is configured to analyze • addressMapControlDroppedFrames: total number of received frame for this interface that the probe chose not to count (out of resources)

  41. Address Map Group (3) • The addressMapTable will collect address mapping 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)

  42. Address Map Group (4) • The addressMapTable consists of • addressMapTimeMark : a time filter for this entry • addressMapNetworkAddress : the network address for this entry • addressMapSource : the last interface which the associated network address was seen • addressMapPhysicalAddress : the last source MAC address on which the associated network address was seen • addressMapLastChange : the value of sysUpTime at the time this entry was most recently updated

  43. Network-layer Host Group (1) • nlHost group enables users to decode packets based on their network-layer address • This group consists of 2 Tables • nlHostControlTable : control table • nlHostTable : data table

  44. Fig 10.11

  45. Network-layer Host Group (2) • Each row in control table refers to a unique interface of the monitor • nlHostControlTable • nlhostControlIndex : an integer that uniquely identifies a row in the nlHostControlTable • nlHostControlDataSource : identifies the interface that is the source of the data for the data tableentries defined by this row • nlHostControlNlDroppedFrames : total number of received frames for this interface that the probe chose not to count for the associated nlHost entries

  46. Network-layer Host Group (3) • nlHostControlNlInserts : the number of times an nlHost entry has been inserted into the nlHostTable data table • nlHostControlNldeletes : the number of times an nlHost entry has been deleted from the nlHostTable data table • nlhostControlNlMaxDesiredEntries : the desired maximum number of entries in nlHostTable

More Related