TCP/IP Network Management 635.413.31 – Summer 2007

1. TCP/IP Network Management635.413.31 – Summer 2007

2. Managing an Internet Introduction • Network Management is the act of monitoring and controlling the hardware, software, and systems that comprise an internet • The ISO defines five areas of Network Management: • Configuration Management: aka change management; handles things like moves, adds, & deletes as well as managing software licenses • Fault Management: the detection, isolation, and correction of anomalous or unusual operational states in the network and its components • Performance Management: concerned with aspects of network management like modeling, capacity planning, and the efficient use of resources • Accounting Management: What and how many resources are being used by whom • Security Management: areas such password and encryption key management; processes like logging and auditing.

3. Managing an Internet Introduction (2) • Difficulties with Internet Management typically arise for two reasons: • Networks are heterogeneous (both in equipment and vendors) • Networks (especially internets) can get very large and complex • The Network Management paradigm for internets must offer three important capabilities: • A single manager/management system can control a wide range of devices (routers, switches, printers, etc.) • Common data link and physical layer protocols are not required • The devices controlled do not have to be on the same network with the manager/management system – they can reside anywhere on the ‘managed internet’ • Result: application layer management protocols & software • Allows the commonality & flexibility to meet the capabilities above • If the network is not working properly the management capability may not work either

4. Managing an Internet Introduction (3) • One note about network/internet management • In network management the most severe problems are (usually) the easiest to diagnose & fix, while the intermittent problems can be the most difficult to solve • One of the main reasons for this was that TCP/IP was designed to be robust and work in an unreliable environment (though this desirable characteristic can mask a number of problems) • Even though things may still work from a user’s perspective they should be found and fixed for two reasons: 1. Intermittent failures will increase network load and decrease it’s performance, throughput, and response time 2. Many intermittent failures are signs of components on the verge of failure

5. Network Management Systems and Software Network Management Tools • Though there are some tools already available in the TCP/IP suite for troubleshooting and monitoring, the most important tool for a network manager is the network management system • Other tools to use for rudimentary network management: • Ping • Traceroute • DNS Tools • nslookup • dig • Host Tools • netstat • nbtstat • arp

6. Network Management Systems & Software A network management system has two primary components: network management stations (managers) and agents • Agents are data collection processes in network components that monitor that component’s vital statistics and in some circumstances will alert the manager of ‘interesting’ events • The network management station typically polls the agents for data is interested in and aggregates the data into a representation of the network useful to the network manager • In some instances there are other components in a network management system: • Proxy Agents • Mid-Level Managers • Management ‘consoles’

7. Network Management Systems & Software Network Management System Design • Since the network management system is a distributed system a communications protocol is necessary for managers and agents to communicate • It may seem a bit unusual but in TCP/IP networks the network management system is just another application using the same network and transport layer protocols as other user applications. This was done for three reasons: • In a heterogeneous environment like the Internet, a single management protocol cannot be readily developed • If a hardware failure occurred and prevents communication all protocols at all layers of the stack are going to be cut off (so why try to develop a specialized protocol for network management?) • Using the same protocols means the network manager, in the course of using the network management system, will have some indication of the current state of the network

8. SNMP: The Simple Network Management Protocol Introduction • This protocol was standardized by the IETF for TCP/IP network management; the “current” protocols are versions 2 and 3 • Version 2 provides all the network management functions except security • Version 3 defines comprehensive security extensions for privacy, message authentication, and access control (implementation is still a bit spotty) • All three versions of SNMP are supposed to co-exist when necessary (RFC 3584) • Base SNMPv2 are found in RFCs 3411, 3412, 3413, and 3416 through 3418 (including the base MIBs) • SNMPv3 definitions are in RFCs 3414 and 3415 • A large number of other RFCs define specific behaviors and management of devices • SNMP is connectionless and uses UDP as its transport layer • Well-known UDP ports 161 and 162 are used for operation

9. SNMP: The Simple Network Management Protocol Introduction (2) • SNMP messages are encoded in a standardized format called the Abstract Syntax Notation dot 1 (or ASN.1) • ASN.1 is defined in ISO standards 8824 and 8825 • Provides two main features: a human readable form for information structure & an equivalent compact machine-based encoding for comms. use • ASN.1 uses a TLV (type, length, value) notation for defining the name and value SNMP data objects • ASN.1 also includes Basic Encoding Rules (BER) specifying how to encode the information in a message

10. SNMP: The Simple Network Management Protocol Fundamental Operation of SNMP

11. SNMP: The Simple Network Management Protocol SNMP messages come in seven different flavors (version 2): • GETRequest – request for agent to return the values for the object identifiers contained in the message • GETNEXTRequest – request for agent to return the next object in lexicographical order; this allows the manager to ‘walk’ the MIB and determine its structure • Response – used to reply to a request or return an error condition to a request • SETRequest – used by the manager to set the value of an object instance in an agent • GETBulkRequest – allows a large number of objects to be returned in order without individually specifying each object identifier in the request (not found in SNMPv1) • InformRequest – designed to allow a limited form of SNMP manager-to-manager communication (not found in SNMPv1) • TRAP – used by an agent to notify a manager asynchronously that an event has occurred

12. SNMP: The Simple Network Management Protocol • SNMP Operation • The SNMP protocol uses a very simple command-response type operation • If a Manager sends a GETRequest message the agent must respond with a Response message • The response message either contains the requested data or one of the following error conditions: noSuchName, tooBig, badValue, genError, etc. • If a Manager sets a threshold for an ‘interesting’ event when that event occurs the Agent must return a TRAP message to the manager • SNMP is oriented mostly towards monitoring of conditions though some devices allow their agents an indirect form of control and data manipulation • Example: reset counters • Another example: rebooting a managed system

13. SNMP: The Simple Network Management Protocol • SNMP Data Structure • The data stored and accessed by SNMP agents & managers are ordered in a logical tree structure called the Management Information Base (MIB) • SNMP itself does not define the MIB; MIBs are typically defined in their own RFCs • The standardized structure of a MIB and MIB objects is defined in an RFC called the Structure of Management Information (RFC 2578) • SNMP does not specify the MIB structure nor the objects it contains to make the protocol more flexible: • Allows easy definition of new objects for managing new equipment and expanded functionality • Reduces changes to the core protocol, which enhances interoperability • It is very important for you as network manager to know what MIBs your management systems and agents support! • It is also important to note that MIBs define a logical description of data structure; the data structure internal to a system can be different

14. SNMP: The Simple Network Management Protocol • SNMP Data Structure (continued) • Most agents support more than one MIB; a large variety of MIBs have been defined for specialized applications • The most general (and widely supported) MIB is formally called MIB-II and contains the following subgroups of related objects: • System – overall info on the system • Interfaces – information about each network interface on the system • Address Translation (deprecated) –not used anymore • IP – statistics related to the Internet Protocol • ICMP – statistics related to the Internet Control Message Protocol • TCP - statistics related to the Transmission Control Protocol • UDP - statistics related to the User Datagram Protocol • EGP - statistics related to the use & functioning of an Exterior Gateway Protocol • Transmission – some statistics related to the underlying transmission systems and protocols used on the interfaces • SNMP – information & statistics related to the functioning of the agent in this component

15. SNMP: The Simple Network Management Protocol MIB-II Object Naming and Structure:

16. SNMP: The Simple Network Management Protocol • Notes from Previous Diagram • The Namespace provides for a unique name or OID (Object Identifier) assigned to any managed object • The namespace is controlled by a top-level organization but control is delegated at lower levels of the hierarchy (like DNS) • Names/OIDs have both a human-friendly name and an equivalent numerical representation • OID for private MIB object-space is 1.3.6.1.4 • Equivalent ‘friendly’ name is iso.org.dod.internet.private • If (say) Cisco were to build their own MIB and objects they would likely be under iso.org.dod.internet.private.cisco • Pay attention to absolute names/OIDs versus relative names/OIDs!

17. SNMP: The Simple Network Management Protocol More About MIBs • Other MIBs have been defined to cover different transmission media and protocols in more detail • Examples: • Bridge MIB (RFC 1286) • FDDI MIB (RFC 1285) • IEEE 802.5 Token Ring MIB (RFC 1231) • X.500 Directory Monitoring MIB (RFC 1567) • UPS MIB (RFC 1628) • Private MIBs – vendors can (and do) provide specially defined MIBs for more in-depth monitoring and control of their equipment and services than is available through the standard MIBs

18. SNMP: The Simple Network Management Protocol • A special MIB: RMON • The RMON or Remote Monitoring MIB was developed to extend the SNMP management capability beyond what standard MIBs can provide • MIB-II and other MIBs collect device level statistics; it can be hard to piece together a system or network level view from all this ‘low-level’ information • Can also provide quicker and more efficient network information without having to poll all agents on a network • RMON allows the collection of data through the use of devices or modules called network probes • Network probes operate in ‘promiscuous’ mode – reading and analyzing all data on the network no matter who it is addressed to • Probes can not only collect network level statistics but can also capture ‘interesting’ packets or packet flows • Generally one probe is necessary per network (usually defined as a broadcast domain)

19. SNMP: The Simple Network Management Protocol • Design goals of RMON • Off-line operation: the RMON probe collects fault, performance, and configuration data even when not being polled by the network manager (a bit more autonomous than an agent) • Pre-emptive monitoring: the probe should, under the right circumstances, be able to run network diagnostics and notify the management station of any information useful for diagnosing and solving the problem • Problem detection & reporting: passive operation as opposed to pre-emptive (active) monitoring • Value-added data: probe should be able to perform some basic analyses on collected data; relieving some of that burden from the network management station • Multiple managers: the probe should be able to interact with more than one management station; preferably simultaneously

20. SNMP: The Simple Network Management Protocol • RMON MIB groups • Statistics: general network statistics (total packets, collisions, broadcasts, etc.) • History: records periodic statistical samples from Statistics group • Alarm: Manager set alarm thresholds • Host: Collects statistics on traffic to and from all hosts on the network • HostTopN: lists of sorted statistics on hosts (Top 10 talkers, etc.) • Matrix: shows error and utilization statistics between pairs of hosts • Filter: sets up packet capture filters • Packet Capture: holds captured packets that meet Filter group criteria • Events: table of all events generated by the RMON group • An example MIB (handout)

21. SNMP: The Simple Network Management Protocol • SNMP Version 3 • Previous versions had no security beyond a clear-text ‘password’ • Security mechanisms were proposed for v2, but were dropped due to controversy over implementation details • Consequentially, SNMPv1 and v2 were used primarily for monitoring (as opposed to management) • SNMPv3 finally adds privacy, authentication, & access control to the protocol – in essence v3 is “v2 plus administration & security” • What does version 3 have? • Provides a re-write of earlier core standards to make SNMP more modular & extensible and to clarify specifics in the protocol • Provides authentication & privacy via the User-Based Security Model • Provides access control via the View-Based Access Control Model (VACM) • Implementation of v3 still spotty due to implementation challenges

22. SNMP: The Simple Network Management Protocol • SNMP Version 3 Administrative Details • We won’t discuss most of the details, but to note the general architectural model used for any SNMP ‘entity’ • Entities consist of at least one application & at least one engine • Managers, Agents, & other SNMP devices are specific implementations of the general ‘entity’ model

23. SNMP: The Simple Network Management Protocol • SNMP Version 3 Administrative Details • Entity Model Components • Dispatcher: send/receives SNMP messages (may sort by version) • Message Processing Subsystem: prepare messages for transmission/extract data from received messages • Security Subsystem: implement USM (potentially multiple modules) • Access Control Subsystem: implement VACM • Command Generator: initiates GET, GET-NEXT, etc. messages • Command Responder: generates appropriate RESPONSE msgs. • Notification Originator: generates appropriate TRAP/INFORM messages • Notification Receiver: handles/processes Inform messages; may generate subsequent INFORM messages • Proxy Forwarder: if needed forward SNMP messages

24. SNMP: The Simple Network Management Protocol • SNMP Version 3 User-Based Security Model (USM) • Provides authentication and privacy for version 3 messages • The basic SNMP commands/functions do not change, but the message must to allow for the added security functions • DES-CBC used as the basic privacy mechanism • Note: key management is outside the scope of SNMPv3 • MD5 (mandatory) or SHA (optional) can be used as the basic authentication mechanism • Replay protection via synchronization & message time-window checking • The standard is extensible as it is planned that other privacy and authentication options will be developed in the future

25. SNMP: The Simple Network Management Protocol • SNMP Version 3 User-Based Security Model (USM)

26. SNMP: The Simple Network Management Protocol • Designed to allow different levels of access to a entity-based (typically agent) MIB • Group-based • How policy is pre-configured is outside the scope of VACM • Two Components: • Limit the operations allowed on a portion of a MIB (read only, etc.) • Totally restrict a portion of a MIB • SNMP v3 View-Based Access Control Module (VACM)

27. SNMP: The Simple Network Management Protocol • Example SNMP Network Management Systems • Low-end • Castlerock SNMPc • Ipswitch What’s Up Gold • Intermediate • HP Openview NNM (Network Node Manager) • CiscoWorks • (Open-Source) OpenNMS – www.opennms.org • Complex • Aprisma (Computer Associates) Spectrum • Tivoli (IBM) Netview • Lucent/Alcatel VitalSuite

28. Reading & Homework • Reading • Chapter 29 [Internet Management]