CN8861 Network Management Lecture-6 15 June 2014

1. CN8861Network ManagementLecture-615 June 2014 Govi Ravindran Dept. of Electrical & Computer Engineering Ryerson University

2. Section 1Distributed Management

3. RFC References – Distributed Management • RFC 3165, “Definitions of Managed Objects for the Delegation of Management Scripts” • RFC 3231, “Definitions of Managed Objects for Scheduling Management Operations” • RFC 2982, “Distributed Management Expression MIB”

4. Overview • Distributed Management System • Definition, Characteristics, and Technologies • Distributed Management MIBs • Script MIB • Schedule MIB • Expression MIB

5. Distributed Management Systems • Complexity of Management Tasks • In a centralized system, the central manager carries out the entire management task. • In a weakly distributed system, complex tasks are executed at the top level manager whereas simple management tasks are delegated to mid-level managers. • Strongly distributed systems decentralize management processing to each and every network element; management tasks are no longer confined to managers.

6. Distributed Management Systems • Computational load on the top-level manager is reduced by delegating functions elsewhere. • Resource requirements at the top-level manager is reduced. • The communication load on the network is reduced. • By locating mid-level managers as close to the devices as possible, only processed data moves between managers. • With dynamic delegation, management tasks can be assigned and changed dynamically.

7. Distributed Management MIBs • IETF Distributed Management (DISMAN) Working Group had proposed standard MIBs to realize • Distributed Managers and/or • Self-Managing devices • The DISMAN MIBs that are of interest include: • Schedule MIB • Script MIB • Expression MIB

8. IETF Distributed Management MIBs internet {.iso.org.dod 1} mgmt {internet 1} mib-2 {mgmt 1} Script MIB (scriptMIB) Schedule MIB (schedMIB) Event MIB (dismanEventMIB) Expression MIB (dismanExpressionMIB) {mib-2 63} {mib-2 64} {mib-2 88} {mib-2 90}

9. Script MIB • Script MIB defines managed objects for delegation of management functions. • Management functionality is delegated as scripts which are transferred to the location where they are executed. • The Scripts can be started remotely, arguments can be passed to them, and results can be returned back to the initiator.

10. Script MIB - Capabilities • Script MIB provides following capabilities: • Transfer management scripts to a distributed manager. • Transfer arguments for management scripts. • Initiate, suspend, resume or terminate management scripts. • Monitor and control running management scripts. • Transfer the results produced by the management scripts.

11. Script MIB – Script Transfer • There are two different ways to transfer management scripts to a distributed manager: • Push Model: The high-level manager pushes the script to the distributed manager. • Pull Model: The manager tells the distributed manager the location of the script and the distributed manager retrieves the script itself. • The Script MIB also supports management scripts that are part of the Script MIB implementation. • Scripts are stored in an non-volatile storage. This allows a distributed manager to restart scripts. • Every script is identified by an administratively assigned name.

12. Script MIB – Framework

13. Script MIB – Script Transfer • The ‘push model’ is realized by a table which allows a manager to write scripts by sending a sequence of SNMP set requests. • The ‘pull model’ is realized by the use of URLs that point to the script source. • The manager writes the URL by an SNMP set request. • The distributed manager is then responsible for retrieving the script using the protocol specified in the URL (such as FTP or HTTP).

14. Script MIB – Script Execution • The Script MIB allows execution of management scripts • Arguments can be passed to a script. • Scripts can return a single result value. • Scripts can also export complex results. For instance, a URL can be returned that points to afile containing script output. • When runtime errors terminate active scripts, an exit code and an error message is left in the MIB. • Running scripts have associated status object which allows script execution to be suspended, resumed, or aborted. • A history of finished scripts is kept in the MIB.

15. Distributed Management Script MIB scriptMIB {.iso.org.dod.internet.mgmt.mib-2 64} smNotifications {scriptMIB 2} smObjects smConformance {scriptMIB 1} {scriptMIB 3} smTraps smScriptException smScriptAbort smScriptResult smExtsnTable smScriptObjects smRunObjects smLangTable smCodeTable smScriptTable smRunTable smLaunchTable

16. Script MIB – Language Group • Language Group • The smLanguageGroup is used to provide information about the languages and the language extensions supported by a Script MIB implementation. This group includes two tables. The smLangTable lists all languages supported by a Script MIB implementation and the smExtsnTable lists the extensions that are available for a given language.

17. Script MIB – Script Group • Script Group • The ‘smScriptGroup’ consists of a single table called ‘smScriptTable’ which lists all scripts known to a Script MIB implementation. • The source of a script is defined by the ‘smScriptSource’ object. • ‘smScriptSource’ may contain a URL pointing to a remote location. • If the ‘smScriptSource’ is null, the script source is read from the smCodeTable or from local storage. • The ‘smScriptStorageType’ object is used to distinguish between scripts read from local storage and scripts read from the smCodeTable.

18. Script MIB – Script Group • Scripts are automatically loaded once the ‘smScriptAdminStatus’ object is set to ‘enabled’. • Loading a script includes retrieving the script, compiling (if required), and making the code available to the runtime system. • The ‘smScriptOperStatus’ object is used to indicate the status of the loading process. • ‘smScriptOperStatus’ object will start in the state ‘retrieving’, switch to the state ‘compiling’ and finally reach the state ‘enabled’. • Errors during the retrieval or compilation phase will result in an error state such as `compilationFailed'.

19. Script MIB – Script Group smScriptObjects {scriptMIB.smObjects 3} smScriptTable smCodeTable {smScriptObjects 1} {smScriptObjects 2} smScriptOwner smCodeIndex smScriptName smCodeText smScriptDescr smCodeRowStatus smScriptLanguage smScriptSource smScriptAdminStatus smScriptOperStatus smScriptStorageType smScriptRowStatus smScriptError smScriptLastChange

20. Script MIB – Code Group • The smCodeGroup consists of a single table, the ‘smCodeTable’ • ‘smCodeTable’ provides the ability to transfer and modify scripts via SNMP set requests. • A script can be fragmented over multiple rows of the smCodeTable in order to handle SNMP message size limitations.

21. Script MIB – Launch Group • The smLaunchGroup contains a single table, the smLaunchTable. • The smLaunchTable allows the following operations: • associate a script with an owner used during script execution • provide arguments and parameters for script invocation • invoke scripts with a single set operation

22. Script MIB – Launch Group smRunObjects {scriptMIB.smObjects 4} smLaunchTable {smRunObjects 1} smLaunchControl smLaunchOwner smLaunchAdminStatus smLaunchName smLaunchOperStatus smLaunchScriptOwner smLaunchRunIndexNext smLaunchScriptName smLaunchStorageType smLaunchArgument smLaunchRowStatus smLaunchMaxRunning smLaunchError smLaunchMaxCompleted smLaunchLastChange smLaunchLifeTime smLaunchRowExpireTime smLaunchExpireTime smLaunchStart

23. Script MIB – Run Group • Every row in the smRunTable contains the argument passed during script invocation, the result, the script exit code, run state, and start and end time-stamps. • There are three writable objects in the smRunTable: • The smRunLifeTime object defines the maximum time a running script may run before it is terminated by the Script MIB implementation. • The smRunExpireTime object defines the time that a completed script can stay in the smRunTable before it is aged out. • The smRunControl object allows running scripts to be suspended, resumed, or aborted.

24. Script MIB smRunObjects {scriptMIB.smObjects 4} smRunTable {smRunObjects 2} smRunIndex smRunArgument smRunStartTime smRunEndTime smRunLifeTime smRunExpireTime smRunExitCode smRunResult smRunControl smRunState smRunError smRunResultTime smRunError

25. IETF Script MIB

26. IETF Script MIB

27. Script MIB – Application • Software update: • Updating and configuring software on a managed node • Following scripts can be used to accomplish the above: • a script checking the version currently installed, • a script to stop and uninstall the old software release, • an install script for the new release, and a • a configure script for the new release

28. Schedule MIB • Schedule MIB supports scheduling of actions periodically or at specified dates and times. • The actions can be used to trigger management functions in a distributed manager. • Schedules can be enabled or disabled by modifying a control object.

29. Schedule MIB – Schedules • Periodic schedules are based on fixed time periods between the initiation of scheduled actions. • Calendar schedules trigger scheduled action at specified days of the week and/or days of the month. • One-shot Schedules are similar to calendar schedules. The difference is a one-shot schedule will automatically disable itself once it has been invoked.

30. Schedule MIB – Actions • Scheduled actions are invoked by SNMP set operations on local MIB variables. • Scheduled actions in the Schedule MIB are further restricted to objects of type INTEGER. • Simple actions such as setting a status MIB object (e.g. ifAdminStatus). • Complex actions such as triggering a management script.

31. Distributed Management Schedule MIB schedMIB {.iso.org.dod.internet.mgmt.mib-2 63} schedNotifications {schedMIB 2} schedObjects schedConformance {schedMIB 1} {schedMIB 3} schedTraps schedTable schedLocalTime schedActionFailure schedOwner schedVariable schedName schedValue schedDescr schedType schedInterval schedAdminStatus schedWeekday schedOperStatus schedMonth schedFailures schedDay schedLastFailure schedHour schedLastFailed schedStorageType schedMinute schedRowStatus schedContextName schedTriggers

32. Expression MIB • The Expression MIB is a powerful way to monitor large, complex systems. • Expression MIB is a way to create new, customized MIB objects for monitoring. • Expression MIB supports externally defined expressions of existing MIB objects. • In the Expression MIB the results of an evaluated expression are MIB objects that are used like any other MIB objects. • Without these capabilities monitoring would be limited to the objects in predefined MIBs. • The MIB is usually appropriate in a relatively powerful, resource-rich managed system and not necessarily in a severely limited environment.

33. Expression MIB - Sampling • The MIB supports three types of object sampling for the MIB objects that make up the expression: absolute, delta, and changed. • Absolute samples are simply the value of the MIB object at the time it is sampled. • Delta sampling requires the implementation to maintain the value of the last sample. • Changed sampling is a boolean indicating whether or not the object changed value since the last sample.

34. Expression MIB - Evaluation • If there are no delta or change values in an expression, the evaluation occurs on demand, i.e. when a requester attempts to read the value of the expression. In this case the requester gets a freshly calculated value. • For expressions with delta or change values, evaluation goes on continuously, every sample period. In this case requesters get the value as of the last sample period.

35. Simple Expression MIB • No wildcards • Such an implementation would allow expressions made up of individual MIB objects but would not be suitable for expressions applied across large tables as each instance in the table would require a separate expression definition. • Furthermore it is suitable for tables with arbitrary, dynamic instances, as expressions definitions could not predict what instance values to use. • Significantly reduces retrieving and processing complexity • No deltas • Leaving out delta processing significantly reduces state that must be kept and processing burden. • Unfortunately it makes expressions on counters unusable, as counters have meaning only as deltas. • An implementation without deltas might be useful for a resource limited, self-managing system that has no need for expressions or events on counters.

36. Expression MIB – Structure • Resource Section • Has objects to manage resource usage by wildcardeddelta expressions, a potential major consumer of CPU and memory. • Definition Section • Contains the tables that define expressions. • The expression table contains parameters that apply to the entire expression, such as the data type of the result, and the sampling interval if it contains delta or change values. • The object table contains the parameters that apply to the individual objects that go into the expression, including the object identifier, sample type, discontinuity indicator, and such. • Value Section • Contains the values of evaluated expressions. • For a given expression only one of the columns is instantiated, depending on the result data type for the expression.

37. Expression MIB - Structure dismanExpressionMIB {.iso.org.dod.internet.mgmt.mib-2 90} dismanExpressionMIBObjects dismanExpressionMIBConformance {dismanExpressionMIB 1} {dismanExpressionMIB 2} expDefine expValue expResource expValueTable expErrorTable expObjectTable expExpressionTable

38. Section 2Service Level Monitoring

39. Defining Delay, Jitter, & Packet loss • Multi-media applications are sensitive to the Delay, Jitter, and Packet Loss characteristics of data networks. • Delay is the time taken for packets to travel across a network. • One-way delay calculations require clock synchronization across nodes, whereas measuring round-trip delay is easier. • Jitter is the variation in delay. • A jitter buffer temporarily stores arriving packets in order to minimize delay variations. • Packet loss describes the %of packets that did not reach their intended destination. • Reasons for packet loss include link failure, network congestion, and Random Early Discard (RED) among others.

40. Cisco IP SLA • Cisco IP SLA is an IOS feature that enables measurement of jitter, latency, or packet loss between network end-points. • IP Services can be simulated by specifying various packet sizes, ports, class of service, packet spacing, and frequencies. • Jitter/Latency/Packet-loss measurements per class of service are made to validate service differentiation for data, voice, and video. • Cisco IP SLA also helps to establish an network performance baseline and allow the user to understand trends and anomalies from the baseline.

41. SAA and RTTMON • Cisco IP SLA is supported by the Service Assurance Agent (SAA) and the Round-Trip Time Monitoring (RTTMON) MIB. • The SAA and the RTTMON MIB are Cisco IOS software features available in versions 12.0 (5)T and higher. • The features enable you to test and collect delay, jitter, and packet loss statistics on the data network. • Cisco IOS routers are used as probes to simulate end points. • The probes can be configured to monitor the network for delay and jitter and alert network management stations when thresholds are exceeded.

42. SLAs for IP Networks SP Converged IP Network P Router Measure Either CE–PE or CE–CE Links Enterprise Site 2 Enterprise Site 1 Measure Either PE–CE or PE-PE Links

43. Send train of packets with constant Interval Receive train of packets at Interval impacted by Network IP Core Responder Source Add a receive time stamp, and calculate delta, the processing time. UDP Jitter Operation • Per-direction inter-packet delay (Jitter) • Per-direction packet loss • Average Round Trip Delay

44. Responder Source Router Target Router Responder T2 T1 T3 T4 D = T3 - T2 • Responder factors out destination processing time making results highly accurate • Responder allows for one-way measurements for latency, jitter, and packet loss.

45. UDP Jitter Operation Interval Number of Packets Frequency Time = IP SLA UDP Jitter test packet – Operation 1 destination1 =IP SLA UDP Jitter test packet – Operation 2 destination2

46. IP SLA Example

47. Polling the RTTMON MIB • The source SLA probe collects and places data in the RTTMON SNMP MIB tables. • rttMonStatsTable • rttMonLatestJitterOper • ‘show rtr collection−stats’

48. Polling the RTTMON MIB saarouter1# show rtr collection−stats Collected Statistics Entry Number: 100 Target Address: 172.18.179.10, Port Number: 14384 Start Time: 13:06:04.000 09:25:00 Tue Mar 21 2000 RTT Values: NumOfRTT: 600 RTTSum: 873 RTTSum2: 1431 Packet Loss Values: PacketLossSD: 0 PacketLossDS: 0 PacketOutOfSequence: 0 PacketMIA: 0 PacketLateArrival: 0 InternalError: 0 Busies: 0 Jitter Values: MinOfPositivesSD: 1 MaxOfPositivesSD: 1 NumOfPositivesSD: 23 SumOfPositivesSD: 23 Sum2PositivesSD: 23 MinOfNegativesSD: 1 MaxOfNegativesSD: 1 NumOfNegativesSD: 1 SumOfNegativesSD: 1 Sum2NegativesSD: 1 MinOfPositivesDS: 1 MaxOfPositivesDS: 1 NumOfPositivesDS: 7 SumOfPositivesDS: 7 Sum2PositivesDS: 7 MinOfNegativesDS: 1 MaxOfNegativesDS: 1 NumOfNegativesDS: 18 SumOfNegativesDS: 18 Sum2NegativesDS: 18

49. Simulating a voice call • Simulating a G.711 voice call: • RTP/UDP port 14384 • 64 Kb/s • 172 byte packets (160 byte payload + 12 byte RTP header) • The jitter probe operation includes: • Send the request to RTP/UDP port number 14384. • Send 172 byte packets • Send 3000 packets for each frequency cycle. • Send every packet 20 milliseconds apart for a duration of 60 seconds and sleep 10 seconds before starting the next frequency cycle. • ((3000 datagrams * 160 bytes per datagram)/ 60sec) * 8 = 64 kb/s

50. Section 3Agent EXtentisibilty (AgentX)