CS Efficient Network Management. Class 6. Danny Raz

Transcription

1 CS Efficient Network Management Class 6 Danny Raz 1

2 Minhalot MidTerm Exam: Next week (12/12/2) in class one hour 2 questions SNMP + thinking Efficiency Example on the Web 2

3 Objectives RMON MIB events alarms Efficient issues in SNMP management Retrieving large tables Get Bulk Case study: GetPrev - An Efficient Way to Browse Large MIB Tables 3

4 RMON - Remote Monitoring Monitoring traffic (say on a LAN) Usually done using Probes or Network analyzers Collecting both statistical information and specific packet information using filters How to get the information out of such a device How to control such a device (what data to collect?) Using the SNMP framework 4

5 RMON - MIB Expanding the capabilities to perform remote monitoring via the SNMP framework by defining a new MIB offline/online operation control the amount of manager agent communication proactive monitoring agent can analyze the data and act accordingly problem detecting and reporting multiple managers either for redundancy or for functionality partitioning 5

6 Atomic row addition Each table row has a attribute called rm1controlstatus This can be: valid undercreation create-request When the set command is used the new row is created with create-request value and then it is set to undercreation When manager is happy with it, it sets the rm1controlstatus value to valid Allows multiple managers to control the same probe 6

7 The RMON MIB rmon (MIBII 16) statistics (1) history (2) alarm (3) host (4) hosttopn (5) matrix (6) tokenring (1) event (9) capture (8) filter (7) 7

8 The Event Group The 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 (alarm) Each evententry may optionally specify that a log entry be created on its behalf whenever the event occurs 8

9 The Event Group Each entry may also specify that notification should occur by way of SNMP trap messages. In this case, the community for the trap message is given in the associated eventcommunity object. The enterprise and specific trap fields of the trap are determined by the condition that triggered the event. Two traps are defined: risingalarm fallingalarm. 9

10 The Alarm Group The Alarm group periodically takes statistical samples from variables in the probe and compares them to thresholds that have been configured The alarm table stores configuration entries that each define a variable, polling period, and threshold parameters If a sample is found to cross the threshold values, an event is generated Only variables that resolve to an ASN.1 primitive type of INTEGER may be monitored in this way 1

11 The Alarm Group alarmindex unique index alarminterval polling interval (seconds) alarmvariable OID of the variable in the RMON MIB alarmsampletype absolute or delta alarmvalue this is the value of the data in last period alarmstartupalarm - rising, falling,, or both alarmrisingthreshold - alarmfallingthreshold - alarmrisingeventindex - alarmfallingeventindex - alarmowner - alarmstatus - EntryStatus - like all other objects To be used by the event table 11

12 The hysteresis mechanism trap trap trap Limits the generation of events when the threshold is crossed many times. This mechanism generates one event as a threshold is crossed in the appropriate direction. No more events are generated for that threshold until the opposite threshold is crossed. 12

13 Sampling a delta value trap trap the probe may implement this mechanism with more precision if it takes a delta sample twice per period Each time comparing the sum of the latest two samples to the threshold This allows the detection of threshold crossings that span the sampling boundary This does not require any special configuration of the threshold value 13

14 RMON - issues Good and bad ways of creating and using MIB Implementation by the agents is the big efficiency issue SNMP can be used for efficient monitoring and control, but Is it the best way? 14

15 An Efficient Way to Browse Large MIB Tables Interactive MIB Browser SNMP Response GetRequest SNMP Response GetRequest SNMP Response GetRequest SNMP Response GetRequest MIB Table. Router 15

16 An Efficient Way to Browse Large MIB Tables Interactive MIB Browser SNMP Response GetRequest SNMP Response GetRequest SNMP Response GetRequest SNMP Response GetRequest MIB Table. SNMP Framework Back does not have a request facilitating? an efficient MIB search in the reverse direction. Router 16

17 The SNMP Bulk Retrieval Problem SNMP shows poor performance when retrieving several thousands of MIB variables in a single logical transaction Reasons: Lack of flow control Bandwidth inefficiency due to OID naming overhead High latency caused by a large number of request/response interactions 17

18 What to do? Always good: improve flow control (work over TCP?) Compress and or change encoding Change the standard: Add a new SNMP command: GetPrev GetSubtree Change the well established MIB design practices add pointers to index of the previous row 18

19 The GetBulk command GetBulkRequest request-id Non-repeaters N Max-Repetition M identification value identification value response retrieve value N M GetNext values request-id Non-repeaters N Max-Repetition M identification value M identification value identification value identification value identification value 19

20 The GetSubTree command GetSubTreeRequest request-id Error status Error index identification value identification value response retrieve sub-tree retrieve sub-tree request-id Error status Error index identification value identification value identification value identification value identification value identification value identification value identification value identification value identification value Sub tree 2

21 GetBulk Vs. GetSubtree CG CR CG CR CG CR CG CR GetNext (row by row) GetNext (rows in parallel) GetBulk GetSubTree 21

22 How to retrieve the previous element? Straightforward technique: linear search from the beginning of a table using GetNext: Bandwidth and time consuming A better technique : retrieve a bulk of a table in advance and then perform local linear search: still wastes bandwidth: increases linearly proportionally to the distance of an entry from the beginning of a table unrelated data in the bulk out of date data Can we do better without Changing the standard? 22

23 Main Ideas Exploiting the fact that a MIB is a fully ordered lexicographic tree and use a binary search rather than the usually deployed linear search Still relying exclusively on the least common denominator of the SNMP framework: SnmpGet SnmpGetNext 23

24 Example

25 Example: GetPrev( ) ?

26 Example: GetPrev( )

27 Step1: Find Maximal Common Prefix

28 Algorithm Building Blocks (I) Binary Search on the length of the input OID approximation using GetNext: Finds maximal common prefix Message complexity is bounded by log 2 (n) where n being length of the OID approximation 28

29 Step2: Find Value of the First Label Following the Maximal Common Prefix

30 Building Blocks (II) Binary Search on the value of the first label following the maximal common prefix using GetNext Both upper and lower bounds are known Message complexity is bounded by log 2 (MAX) where MAX being the maximal value allowed for the component value <

31 Step3: Find Values of other Labels ?

32 Building Blocks (III) For the rest of label values an upper bound for binary search is unknown Thus, every label s s value is found in two steps: Find an upper bound for the value Run binary search on the value using this bound 32

33 How to Find an Upper Bound? Upper_Bound(oid oid,, prefix) { i length(prefix) + 1; high 1; response prefix; while (response < oid) { response SnmpGetNext(prefix.high); high 2 * label i (response); } return high; } The bound is guaranteed to be no more than twice the actual value; Message complexity is bounded by log 2 (MAX) 33

34 Can we do better? Values of the indices of the table entries are not uniformly distributed, but rather clustered We may use this fact to find a tighter upper bound for Binary_Search; Besides each response to GetNext in Upper_Bounds algorithm is a better lower bound than used by default 34

35 Tighter Bounds Works in two phases: 1st phase is the same as in original Upper_Bounds, but we keep track of the low bound sequentially improving it: takes no more than log 2 (MAX) requests and the minimal lower bound attained is MAX/2; 2nd phase searches for the tighter upper bound by initiating a sequence of requests at exponentially increasing distances starting from the lower bound of the 1-st 1 phase takes no more than log 2 (MAX/2) Binary search will also take no more than log 2 (MAX/2) Total Complexity: Ο (log 2 (n) + log 2 (MAX) + (n - 1) * [log 2 (MAX) + 2*log(MAX/2) + 1) 35

36 Remarks The upper bound of the previous slide is only an upper bound. The actual number of request messages used for searching up a value of a specific entry depends on the values of its indices; It does not depend, however, on the position of the entry in the table 36

37 Putting it all Together Input: OID Approximation OID = maximal common prefix OID = OID.<first_label> Step3: Find upper bound Step1: Binary search on length Step2: Binary search on value Sequence of GetNext Binary search on value OID = OID.<first_label> <i-th label> Output: SnmpGet(OID); 37

38 Analysis Overall Message Complexity: O(log 2 (n) + log 2 (MAX) + 2*(n - 1)*log 2 (MAX) + 1) Depends only on table structure and is independent of table size 38

39 Implementation and Experiment Setting: UCDv3.2.6 SNMP Library GetPrev Appl. MIB II:. tcp.tcpconntable ~5 entries Sun Ultra 1 IBM Compatible 166 MHz Pentium II; FreeBSD OS Network: Fast Ethernet. MIB II: ip.ipforwardtable ~3 entries Cisco 75 39

40 Experiments Preparation phase: Download entire table For downloaded table retrieve value of previous OID for elements in positions 5, 1, 15 etc., using four methods: TableWalk: traditional using linear sequence of GetNext requests GetPrev (Basic) GetPrev (TightBounds( TightBounds) GetPrev (Multi-Binding with k=3) 4

41 SNMP table: tcp.tcpconntable closed listen listen listen listen listen listen listen listen listen listen listen established established established established established established

42 tcp.tcpconntable Element # Element # Element # 42

43 ip.ipforwardtable Element # Element # Element # 43

44 Element # Element # Element # 44

45 Time/Bandwidth Tradeoff If time is more important than the overhead, the search can be speed up on expense of extra bandwidth used. The main idea: instead of issuing SnmpGetNext with only one OID approximation, we may pack k approximations into a single PDU. Analysis: reduces the number of iterations by factor log 2 (MAX)/log k+1 (MAX) = log 2 (k+1) increases bandwidth by factor k/log 2 (k+1) In our experiments k = 3 which means twice faster, but 5% more bandwidth 45

46 Conclusion SNMP GetPrev Simple tool that may be used as a building block for efficient MIB browsers Two orders of magnitude faster and two to three orders of magnitude less bandwidth consuming Compatible with all versions of SNMP 46

47 Rest of the Course: Advanced NM Techniques Corba: : using object-oriented technologies for NM Policy based NM Web based NM Mobile code and mobile agents Active Networks Efficient NM 47