Network Management Science

Network Management Systems
CONTENTS
1. Data Communications and Network Management Overview.

Introduction.
Analogy of Telephone Network Management.
Data (Computer) and Telecommunication Network.
Distributed Computing Environment.
TCP / IP-Based Networks: Internet and Intranet.
Communications Protocols and Standards.
Communication Architectures.
Protocol Layers and Services.
Case Histories on Networking and Management.
Case History 1: Importance of Topology (“Case of the Footprint”).
Case History 2: Filtering does not reduce load on node.
Some Common Network Problems.
Challenge of Information Technology Managers.
Network Management: Goals, Organization and Functions.
Goal of Network Management.
Network Provisioning.
Network Operations and NOC.
Network Installation and Maintenance.
Network Management System.
Network and System Management.
Current Status and Future of Network Management.
2. SNMPv1 Network Management: Organization and Information Models.

Introduction.
Managed Network: Case Histories and Examples.
History of SNMP Management.
Internet Organizations and Standards.
Organizations.
Internet Documents.
SNMP Model.
Organization Model.
System Overview.
Information Model.
Introduction.
Structure of Management Information.
Managed Object.
Management of Information Base.
1
3. SNMPv1 Network Management: Communication and Functional Models.

Introduction.
SNMP Communication Model.
SNMP Architecture.
Administrative Model.
SNMP Protocol Specifications.
SNMP Operations.
SNMP MIB Group.
Functional Model.
4. SNMP Management: SNMPv2.

Introduction to SNMPv2 2.
Major Changes in SNMPv2.
SNMPv2 System Architecture.
SNMPv2 Structure of Management Information.
SMI Definitions for SNMPv2.
Information Modules.
SNMP Keywords.
Module Definitions.
Object Definitions.
Textual Conventions.
Creation and Deletion of Rows in Tables.
Notification Definitions.
Conformance Statements.
SNMv2 Management Information Base.
Changes to System Group in SNMPv2.
Changes to SNMP Group in SNMPv2.
Information for Notification in SNMPv2.
Conformance Information in SNMPv2.
Expanded Internet MIB-II.
SNMPv2 Protocol 36.
Data Structure of SNMPv2 PDUs.
SNMPv2 Protocol Operations.
Compatibility with SNMPv1.
Bi-lingual Manager.
SNMP Proxy Server.
5. SNMP Management: RMON.

Introduction.
What is Remote Monitoring?
RMON SMI and MIB.
RMON1.
RMON1 Textual Conventions.
2
RMON1 Ethernet Management Information Base.

Relationship Between Control and Data Tables.
Token Ring RMON Management Information Base.
RMON2.
RMON2 Management Information Base.
RMON2 Conformance Specifications.
ATM Remote Monitoring.
A Case Study on Internet Traffic.
6. Telecommunications Network Management.

Introduction.
Why TMN?
Operation Systems.
TMN Conceptual Model.
TMN Standards.
TMN Architecture.
Functional Architecture.
Physical Architecture.
Information Architecture.
TMN Management Service Architecture.
TMN Integrated View.
Implementation Issues.
Implementation Using OMNIPoint.
7. Network Management Tools and Systems.

Introduction.
Network Management Tools.
Tools Catalog.
BERT.
Basic Software Tools.
SNMP MIB Tools.
Protocol Analyzer.
Network Statistics Measurement Systems.
Traffic Load Monitoring.
Protocol Statistics.
Data and Error Statistics.
Traffic Statistics Using MRTG.
Network Management Systems.
Functional Components.
Multi-NMS Configuration.
Network Management System Requirements.
Commercial Network Management Systems.
System Management.
Commercial System Management Solutions.
3
CA Unicenter TNG.
Tivoli TME.
Low-End System Management.
8. Web-Based Management.
Introduction.
Web Interface and Web Management.
Local and Remote Access.
Web Interface SNMP Management.
Embedded Web-Based Management.
Desktop Management Interface.
Web-Based Enterprise Management.
Java Management API.
Future Direction.
4
UNIT I DATA COMMUNICATIONS AND NETWORK

MANAGEMENT REVIEW
Outline
• Analogy of telephone network

• Data and telecommunication network
• Distributed computing environment
• Internet
• Protocols and standards
• IT management
• Network and system management
• Current status and future of network management
Telephone Network
• Characteristics:
• Reliable - does what is expected of it
• Dependable - always there when you need it (remember 911?)
• Good quality (connection) - hearing each other well
• Reasons:
• Good planning, design, and implementation
5
• Good operation and management of network

Telephone Network Model
• Notice the hierarchy of switches

• Primary and secondary routes programmed
• Automatic routing
• Where is the most likely failure?
• Use of Operations Systems to ensure QoS
Operations Systems / NOC
• Monitor telephone network parameters.

 S/N ratio, transmission loss, call blockage, etc.
• Real-time management of network.
• Trunk (logical entity between switches) maintenance system measures loss and S/N.
• Trunks not meeting QoS are removed before customer notices poor quality.
• Traffic measurement systems measure call blockage.
• Additional switch planned to keep the call blockage below acceptable level.
• Operations systems are distributed at central offices.
• Network management is done centrally from Network Operations Center (NOC).
6
Data and Telecommunication Network
 Computer data is carried over long distance by telephone

(telecommunication network).
 Output of telephone is analog and output of computers is digital.
 Modem is used to “modulate” and “demodulate” computer data to analog
format and back.
 Clear distinction between the two networks is getting fuzzier with modern
multimedia networks
IBM SNA Architecture
7
 IBM System Network Architecture (SNA) is a major step in network architecture.

 SNA is based on multitude of (dumb) terminals accessing a mainframe host at a
remote location.
Distributed Computing Environment with LAN
• Driving technologies for DCE:

• Desktop processor
• LAN
• LAN - WAN network
LAN-WAN Network
8
• Major impacts of DCE:

• No more monopolistic service provider
• No centralized IT controller
• Hosts doing specialized function
• Client/Server architecture formed the core
of DCE network
Client/Server Model
• Post office analogy; clerk the server, and the customer the client
• Client always initiates requests
• Server always responds
• Notice that control is handed over to the receiving entity.
Client/Server Examples
9
TCP/IP Based Networks
• TCP/IP is a suite of protocols

• Internet is based on TCP/IP
• IP is Internet protocol at the network layer level
• TCP is connection-oriented transport protocol
and ensures end-to-end connection
• UDP is connectionless transport protocol and
provides datagram service Internet e-mail and much of the network mgmt.
messages are based on UDP/IP
• ICMP part of TCP/IP suite
Internet Configuration
10
• Walk through the scenario of e-mail from Joe to Sally

Architecture, Protocols and Standards
• Communication architecture
• Modeling of communication systems, comprising
• functional components and
• operations interfaces between them
• Communication protocols
• Operational procedures
• intra- and inter-modules
• Communication standards
• Agreement between manufacturers on protocols
of communication equipment on
• physical characteristics and
• operational procedures
11
• Examples: (Students to call out)
Communication Architecture
• Inter-layer interface: user and service provider

• Peer-layer protocol interface
• Analogy of hearing-impaired student
• Role of intermediate systems
• Gateway: Router with protocol conversion as
gateway to an autonomous network or subnet
OSI Reference Model
12
• Importance of the knowledge of layer structure

in NM
OSI Layers and Services
13
• Importance of services offered by different layers

and the protocol conversion at different layers in NM
PDU Communication Model
• What is the relevance of PDU model in NM?
Gateway
14
• cc:mail from a station in Novel IPX network to

an Internet station with SMTP e-mail
SNA, OSI, and Internet
15
• Similarity between SNA and OSI

• Simplicity of Internet; specifies only layers 3 and 4
• Integrated application layers over Internet
• Commonality of layers 1 and 2 - IEEE standard
Application Protocols
Internet user OSI user
Telnet Virtual Terminal
File Transfer Protocol File Transfer Access & Mgmt
16
Simple Mail Transfer Message-oriented Text

Protocol Interchange Standard
Simple Network Common Management

Management Protocol Information Protocol
NM Case Histories
• The case of the Footprint

• Case of the crashing bridge
Common Network Problems
• Loss of connectivity
• Duplicate IP address
• Intermittent problems
• Network configuration issues
• Non-problems
• Performance problems
17
Challenges of IT Managers
• Reliability
• Non-real time problems
• Rapid technological advance
• Managing client/server environment
• Scalability
• Troubleshooting tools and systems
• Trouble prediction
• Standardization of operations - NMS helps
• Centralized management vs “sneaker-net”
Network Management
• OAM&P
• Operations
• Administration
• Maintenance
• Provisioning
NM Functional Flow Chart
18
NM Components
19
Interoperability
• Message exchange between NMSs managing

different domains
Status and Future Trends
• Status:
• SNMP management
• Limited CMIP management
• Operations systems
• Polled systems
• Future trends:
• Object-oriented approach
• Service and policy management
• Business management
• Web-based management
20
UNIT II
SNMPV1 NETWORK MANAGEMENT-ORGANIZATION

AND INFORMATION MODELS
Case Histories
• AT&T Network Management Centers

• Network Control Centers
• Network Operations Center
• CNN World Headquarters
• Centralized troubleshooting of NIC
• Performance degradation due to NMS
• Bell Operating company procedure
Managed LAN
One of the visits was to an AT&T network control center, which monitored the network
status of their network in the entire eastern half of the United States.We couls see on a very large
screen the network of nodes and links, mostly in green, indicating that the network was
functioning well. The display screen would refresh automatically every few minutes. We saw
nodes or links change color to yellow or red, indicating a minor or major alarm. We would also
then see them turn back to green without human interference. What we were seeing was
monitoring of a national network from a central monitoring center. The monitoring was done by
the network management systems and operations support system s without human intervention.
Even the healing of the network after a failure was accomplished automatically; it was a self-
healing network. Any persistent alarm was pursued by the control center, which tested the
network remotely using management tools to isolate and localize the trouble. It was an
impressive display of the network management capability.
In another visit to a major international news network’s world headquarters, we were
shown the monitoring of not only network failures, but also the performance of networks around
the globe. The NOC personnel were able to look at the networks in the various continents
separately, as well as the global integrated network. The system was putting out not only alarms,
but also the causes of the failures, which was accomplished using the artificial intelligence built
into system.
When asked what is the greatest benefit of a network network management system, one
manager answered that it is the consistency of administering, for example configuring, the
network.
Let us now illustrate what an NMS can do by monitoring a subnetwork that is using a
commercial network management system.
21
• NMS on subnet 192.168.252.1 manages the router and

the hubs on subnet 172.16.46.1 across the backbone
network
Managed Hub: System Information
• Information obtained querying the hub

• Data truly reflects what is stored in the hub
Managed Router: System Information
22
Managed Hub: Port Addresses
• Information acquired by the NMS on hub interfaces

• Index refers to the interface on the hub
• Link address is the MAC address
• The second row data is a serial link
Managed Router: Port Addresses
• Information acquired by NMS on the router interfaces

• Index refers to the interface on the router
• LEC is the LAN emulation card
23
• Ethernet 2/0 interface refers to the interface

card 2 and port 0 in that card
Internet SNMP Management
• 1970’s Advanced Research Project Agency Network (ARPANET)

Internet control Message Protocol (ICMP)
• Internet Engineering Task Force (IETF)
• 1990 SNMPv1
• 1995 SNMPv2
• 1998 SNMPv3
• Internet documents:
• Request for Comments (RFC)
• IETF STD Internet Standard
• FYI For your information
• Source for RFCs
• ftp://nic.mil/rfc
• ftp://ftp.internic.net/rfc
• http://nic/internet.net/
SNMPv1 & SNMPv2 Documents
24
SNMP Model
• Organization Model
• Relationship between network element,
agent, and manager
• Hierarchical architecture
• Information Model
• Uses ASN.1 syntax
• SMI (Structure of Management Information
• MIB ( Management Information Base)
• Communication Model
• Transfer syntax
• SNMP over TCP/IP
• Communication services addressed by messages
• Security framework community-based model
Two-Tier Organization Model
• Any host that could query an agent is a manager
Three-Tier Organization Model: RMON
25
• Managed object comprises network element and

management agent
• RMON acts as an agent and a manager
• RMON (Remote Monitoring) gathers data from MO,
analyses the data, and stores the data
• Communicates the statistics to the manager
Three-Tier Organization Model: Proxy Server
• Proxy server converts non-SNMP data from non-SNMP objects to SNMP compatible
objects and messages
System Architecture
26
• Messages between manager and agent

• Direction of messages - 3 from manager and
2 from agent
SNMP Messages
• Get-Request
• Sent by manager requesting data from agent
• Get-Next-Request
• Sent by manager requesting data on the next
MO to the one specified
• Set-Request
• Initializes or changes the value of network
element
• Get-Response
• Agent responds with data for get and set
requests from the manager
• Trap
• Alarm generated by an agent
Information
• Structure of Management Information (SMI)

(RFC 1155)
• Managed Object
• Scalar
• Aggregate or tabular object
• Management Information Base (RFC 1213)
• RFCs can be downloaded from ftp.internic.net/rfc
Managed Object
27
• Object type and data type are synonymous

• Object identifier is data type, not instance
• Object instance IP address (See Figure 4.2)
Managed Object: Multiple Instances
• All 3 Com hubs of the same version have identical

identifier; they are distinguished by the IP address
• Each IP address is an instance of the object
Name
Uniquely defined by
• DESCRIPTOR AND
• OBJECT IDENTIFIER
Example
ipAddrTable ip 20
28
Internet Subnodes
directory OBJECT IDENTIFIER ::= {internet 1}

mgmt OBJECT IDENTIFIER ::= {internet 2}
experimental OBJECT IDENTIFIER ::= {internet 3}
private OBJECT IDENTIFIER ::= {internet 4}
Private MIB Example
• private MIB intended for vendor equipment

• IANA (Internet Assigned Numbers Authority) assigns
identifiers
29
SNMP ASN.1 Data Type
Primitive Data Types
• get-request message has NULL for value fields and

get-response from agent has the values filled in
• subtype:
• INTEGER (0..255)
• OCTET STRING (SIZE 0..255)
• OCTET STRING (SIZE 8)
Enumerated
• Special case of INTEGER data type
30
• noError NULL by convention
Defined or Application Data Type
• Defined data types are simple or base types

• Opaque is used to create data types based on
previously defined data types
Constructor or Structured Data Type: SEQUENCE
• List maker
31
Constructor or Structured Data Type: SEQUENCE OF
SEQUENCE OF Example
• The above example (Figure 4.3) uses part of the

IP MIB discussed for SEQUENCE OF construct
Encoding
• Basic Encoding Rules (BER)

• Tag, Length, and Value (TLV)
32
• SNMP Data Types and Tags

Type Tag
OBJECT IDENTIFIER UNIVERSAL 6
SEQUENCE UNIVERSAL 16
IpAddress APPLICATION 0
Counter APPLICATION 1
Gauge APPLICATION 2
TimeTicks APPLICATION 3
Opaque APPLICATION 4
Managed Object: Structure
Managed Object: Macro
33
Aggregate Object
• A group of objects
• Also called tabular objects
• Can be represented by a table with
• Columns of objects
• Rows of instances
• Example: IP address table
34
• Consists of objects:
• IP address
• Interface
• Subnet mask (which subnet this address
belongs to)
• Broadcast address (value of l.s.b. in IP
broadcast address)
• Largest IP datagram that can be assembled
• Multiple instances of these objects associated with
the node
Aggregate M.O. Macro: Table Object
ipAddrTable OBJECT-TYPE
::= {ip 20}
ipAddrEntry OBJECT-TYPE
::= {ipAddrTable 1}
Aggregate M.O. Macro: Entry Object
35
• Index ipAdEntAddr uniquely identifies an instance

• May require more than one object in the instance to
uniquely identify it
Aggregate M.O. Macro: Columnar Objects
36
Tabular Representation of Aggregate Object
• •The objects TABLE T and ENTRY E are objects that

are logical objects. They define the grouping and are
not accessible• Columnar objects are objects that represent the
attributes and hence are accessible Each instance of E is a row of columnar objects
1 through 5
• Multiple instances of E are represented by multiple rows
Tabular Representation of Aggregate Object
37
• Notice that the column-row numeric designation is

reverse of what we are used to as row-column
Multiple Instances of Aggregate Managed Object
SMI Definition STD 16 / 1155 RFC
38
• EXPORTS identifies the objects that any other module

could import
SMI Definition STD 16 / 1155 RFC
UNIT III
SNMPV1 NETWORK MANAGEMENT-

COMMUNICATION AND FUNCTIONAL MODELS
Network Management
• Organization Model (ch. 4)
39
– 2 tier
– 3 tier
• Information Model (ch. 4)
– SMI
– MIB
• Communication Model (ch. 5)
• Functional Model (ch. 5)
SNMP Architecture
• Truly simple network management protocol

• Five messages, three from manager and two from agent
SNMP Messages
• Get-Request
• Get-Next-Request
• Set-Request
• Get-Response
• Trap
• Generic trap
40
• Specific trap
• Time stamp
Notes
• Generic trap
• coldStart
• warmStart
• linkDown
• linkUp
• authenticationfailure
• egpNeighborLoss
• enterpriseSpecific
• Specific trap
• for special measurements such as statistics
• Time stamp: Time since last initialization
Administrative Model
• Based on community profile and policy
• SNMP Entities:
• SNMP application entities
- Reside in management stations and network
elements
- Manager and agent
• SNMP protocol entities

- Communication processes (PDU handlers)
- Peer processes that support application entities
SNMP Community
41
• Security in SNMPv1 is community-based

• Authentication scheme in manager and agent
• Community: Pairing of two application entities
• Community name: String of octets
• Two applications in the same community communicate with each other
• Application could have multiple community names
• Communication is not secured in SNMPv1 - no encryption
Community Profile
• MIB view
• An agent is programmed to view only a subset of managed objects of a network
element
• Access mode
• Each community name is assigned an access
mode:: read-only and read-write
• Community profile: MIB view + access mode
• Operations on an object determined by community profile and the access mode
of the object
• Total of four access privileges
• Some objects, such as table and table entry are non-accessible
42
Access Policy
• Manager manages Community 1 and 2 network components via Agents 1 and 2

• Agent 1 has only view of Community Profile 1, e.g. Cisco components
• Agent 2 has only view of Community Profile 2, e.g. 3Com components Manager has
total view of both Cisco and 3Com components
Generalized Administration Model
• Manager 1 manages community 1, manager 2 community 2,and manager 3 (MoM) both

communities 1 and 2
43
Proxy Access Policy
• Proxy agent enables non-SNMP community elements to be managed by an SNMP

manager.
• An SNMP MIB is created to handle the non-SNMP objects
Protocol Entities
• Protocol entities support application entities

• Communication between remote peer processes
• Message consists of
• Version identifier
• Community name
• Protocol Data Unit
• Message encapsulated and transmitted
Get and Set PDU
44
• VarBindList: multiple instances of VarBind pairs
PDU Types: enumerated INTEGER
Error in Response
Error Index: No. of VarBind that the first error occurred (1 if error occurred in virst VarBind, …)
VarBind - pairing of the variable and it’s value
Trap PDU
45
• Enterprise and agent address pertain to the system generating the trap
• Seven generic traps specified by enumerated INTEGER
• Specific trap is a trap not covered by enterprise specific trap time stamp indicates elapsed
time since last re-initialization
SNMP Operations
MIB for Get-Next-Request
46
Lexicographic Order
• Procedure for ordering:

• Start with leftmost digit as first position
• Before increasing the order in the first position,
select the lowest digit in the second position
• Continue the process till the lowest digit in
the last position is captured
• Increase the order in the last position until all
the digits in the last position are captured
47
• Move back to the last but one position and

repeat the process
• Continue advancing to the first position until all
the numbers are ordered
• Tree structure for the above process
MIB Lexicographic Order
48
A More Complex MIB Example
Get-Next-Request Operation
49
Get-Next-Request Operation
Sniffer Data
50
SNMP MIB
Most of the MIB objects were not used and hence deprecated in SNMPv2
Functional Model
51
• No formal specs of functions in SNMPv1

• OSI mode addresses
– configuration
– fault
– performance
– security
– accounting
52
UNIT IV SNMP Management: SNMPv2
SNMPv1
 SNMPv1 Protocol
o RFC 1157 – Simple Network Management Protocol
 SMIv1 Data Definition Language
 Full Standards:
o RFC 1155 - Structure of Management Information
o RFC 1212 - Concise MIB Definitions
 Informational:
o RFC 1215 - A Convention for Defining Traps
 SMIv1 MIB Modules
 Full Standards:
o RFC 1213 - Management Information Base II
o RFC 1643 - Ethernet-Like Interface Types MIB
SNMPv2
 SMIv2 Data Definition Language

 Full Standards:
o RFC 2578 - Structure of Management Information
o RFC 2579 - Textual Conventions
o RFC 2580 - Conformance Statements
 SMIv2 MIB Modules
 Full Standards:
o RFC 2819 - Remote Network Monitoring MIB
o RFC 3411 - SNMP Framework MIB
o RFC 3412 - SNMPv3 MPD MIB
o RFC 3413 - SNMP Applications MIBs
o RFC 3414 - SNMPv3 USM MIB
o RFC 3415 - SNMP VACM MIB
o RFC 3418 - SNMP MIB
SNMPv3
 SNMPv3 Protocol
 Full Standards:
 RFC 3411 - Architecture for SNMP Frameworks
 RFC 3412 - Message Processing and Dispatching
 RFC 3413 - SNMP Applications
 RFC 3414 - User-based Security Model
 RFC 3415 - View-based Access Control Model
53
 RFC 3416 - Protocol Operations Version 2

 RFC 3417 - Transport Mappings for SNMP
 RFC 3418 - SNMP MIB
Major Changes
 Bulk data transfer

 Manager-to-manager message
 Enhancements to SMI: SMIv2
o Module definitions: MODULE-IDENTITY macro
o Object definitions: OBJECT-TYPE macro
o Trap definitions: NOTIFICATION-TYPE macro
 Textual conventions (RFC 2579)
 Conformance statements (RFC 2580)
 Row creation and deletion in table
 MIB enhancements
 Transport mappings
 Security Feature
Structure of Management Information (SMI)
SMIv1, SMIv2
 SMIv1:
o SMI (RFC 1155)
o Concise MIB (RFC 1212)
o Trap-Type (RFC 1215)
 SMIv2:
o SMIv2 (RFC 2578)
o Textual Conventions (RFC 2579)
o Conformance Statements (RFC 2580)
Three Parts of SMIv2
 Module definitions
o MODULE-IDENTITY
 Object definitions
o OBJECT-TYPE
 Notification difinitions
o NOTIFICATION-TYPE
1. MODULE-IDENTITY
54
MODULE-IDENTITY Example
2. OBJECT-TYPE
55
"SYNTAX" Syntax:
(Example) SYNTAX BITS
UnitsPart: UNITS
56
"MAX-ACCESS" Access
"STATUS" Status
57
ReferPart
3. NOTIFICATION-TYPE
NOTIFICATION-TYPE Example
58
OBJECT ??
• OBJECT IDENTIFIER defines the administrative

identification of a node in the MIB
• OBJECT-IDENTITY macro assigns an object
identifier to an object identifier in the MIB
• OBJECT-TYPE macro defines the type of a
managed object
OBJECT-IDENTITY / OBJECT-TYPE
• OBJECT-IDENTITY is high level description

• OBJECT-TYPE details description needed for implementation
59
OBJECT-TYPE
Table Expansion
• Augmentation of a table (dependent table)

adds additional columns to an existing table
(base table)
• Dense table enables addition of more rows to
base table
• Sparse table supplements less rows to a base table
Augmentation of Tables
60
Appending a Spare Table
61
Textual Convention
• Enables defining new data types

• Makes semantics of data types consistent and
human readable
• Creates new data types using existing ones
and applies restrictions to them
• An important textual convention in SNMPv2,
RowStatus creates and deletes rows
SNMPV1:
DisplayString ::= OCTET STRING
62
-- This data type is used to model textual information taken

-- from the NVT ASCII character set. By convention, objects
-- with this syntax are declared as having
-- SIZE (0..255)
SNMPv2:
Creation of Row: RowStatus
63
Create-and-Go Row Creation
Create-and-Wait: Row Creation
64
Row Deletion
SNMPv2 MIB
65
Conformance Statements for SMIv2 (RFC 2580)
 MIB MODULE
o IMPORTS
o EXPORTS
o MODULE-IDENTITY
o TEXTUAL-CONVENTION
o OBJECT IDENTIFIER
o Application Data Types
o OBJECT-TYPE
o NOTIFICATION-TYPE
o OBJECT-GROUP
o NOTIFICATION-GROUP
o MODULE-COMPLIANCE
Four Macros in SNMPv2-CONF
 OBJECT-GROUP macro
 NOTIFICATION-GROUP macro
 MODULE-COMPLIANCE macro
 AGENT-CAPABILITIES macro
Conformance: OBJECT-GROUP
66
• Conformance defined by
• OBJECT-GROUP macro
• NOTIFICATION-GROUP macro
• OBJECT-GROUP
• Compiled during implementation, not at run time
• OBJECTS clause names each object
• Every object belongs to an OBJECT-GROUP
• Access defined by MAX-ACCESS, the maximum
access privilege for the object
OBJECT-GROUP
OBJECT-GROUP Example
67
Conformance: NOTIFICATION-GROUP
• NOTIFICATION-GROUP
• Contains trap entities defined in SMIv1
• NOTIFICATIONS clause identifies the
notifications in the group
• NOTIFICATIONS-GROUP macro compiled
during implementation, not at run time
NOTIFICATION-GROUP
NOTIFICATION-GROUP Example
Compliance
• Compliance has two classes of groups

• MANDATORY-GROUPS ... Required
• GROUP …Optional
68
MODULE-COMPLIANCE
ModulePart
CompliancePart (1/2)
69
CompliancePart (2/2)
MODULE-COMPLIANCE Example
OBJECT-GROUP
70
Agent Capabilities
• AGENT-CAPABILITIES macro
• SUPPORTS modules and includes groups
• VARIATION identifies additional features
AGENT-CAPABILITIES
SNMPv2 Internet Group
71
SNMPv2 New Messages
• inform-request
• manager-to-manager message
• get-bulk-request
• transfer of large data
• SNMPv2-Trap
• transfer of notifications
• Report
• not used
SNMPv2 PDU
72
SNMPv2 PDU
SNMPv2 Error Status
SNMPv2 GetBulkRequest PDU
• Error status field replaced by Non-repeaters

• Error index field replaced by Max repetitions
• No one-to-one relationship between request and response
Get-Bulk-Request:
73
74
Get-Bulk-Request Operation
75
76
77
snmpgetbulk.java
http://www.im.ncnu.edu.tw/ycchen/nm/snmpgetbulk.java
java snmpgetbulk [-m MIB_files] [-c community]

[-nr non-repeaters] [-mr max-repetitions]
host OID [OID] ...
Example:
java snmpgetbulk -m RFC1213-MIB -c comm123
-nr 2 -mr 20 10.10.20.73 sysDescr sysUpTime ifIndex ifDescr ifType
C:\snmp>java snmpgetbulk -m RFC1213-MIB -c public -nr 2 -mr 9 10.10.32.84 sysDescr

sysUpTime ifIndex ifDescr ifType > 84bulk.txt
84bulk.txt:
sysDescr.0:-->DES-3526 Fast-Ethernet Switch

sysUpTime.0:-->15 days, 18 hours, 57 minutes, 11 seconds.
78
Repeaters:
ifIndex.1:-->1 ifDescr.1:-->RMON Port 1 on Unit 1 ifType.1:-->ethernet-csmacd(6)
C:\snmp>java snmpgetbulk -m RFC1213-MIB -c public -nr 2 -mr 9 10.10.34.169

sysDescr sysUpTime ifIndex ifDescr ifType > 169bulk.txt
169bulk.txt:
sysDescr.0:-->Hardware: x86 Family 15 Model 3 Stepping 4 AT/AT COMPATIBLE…

sysUpTime.0:-->12 days, 8 hours, 12 minutes, 10 seconds.
Repeaters:
fIndex.1:-->1 ifDescr.1:-->Loopback interface ifType.1:-->softwareLoopback(24)
ifIndex.2:-->2 ifDescr.2:-->Intel(R) PRO/100 ifType.2:-->ethernet-csmacd(6)
ifDescr.1:-->Loopback interface ifType.1:-->softwareLoopback(24) ifMtu.1:-->1520
ifDescr.2:-->Intel(R) PRO/100 ifType.2:-->ethernet-csmacd(6) ifMtu.2:-->1500
ifType.1:-->softwareLoopback(24) ifMtu.1:-->1520 ifSpeed.1:-->10000000
ifType.2:-->ethernet-csmacd(6) ifMtu.2:-->1500 ifSpeed.2:-->100000000
ifMtu.1:-->1520 ifSpeed.1:-->10000000 ifPhysAddress.1:-->
ifMtu.2:-->1500 ifSpeed.2:-->100000000 ifPhysAddress.2:-->00 11 2f c9
b1 9f
ifSpeed.1:-->10000000 ifPhysAddress.1:--> ifAdminStatus.1:-->up(1)
snmpgetbulk.java
79
Issues in Bulk Data Transfer
 Latency
o End-to-end delay caused by a number of request/response message exchanges
 Network overhead
o Amount of non-data octets carried in each PDU
 Table retrieval problems
o holes in tables
o table consistency
o GetBulk overshoot
Improvements
 SNMP over TCP

 OID compression
 Other encoding methods
 Mobile agent
 GetCols
 GetBulkBumper
 GetSubtree
 GetPrev
 GetModify
SNMPv2 Trap
80
• Addition of NOTIFICATION-TYPE macro

• OBJECTS clause, if present, defines order of variable bindings
• Positions 1 and 2 in VarBindList are sysUpTime and snmpTrapOID
NOTIFICATION-TYPE
NOTIFICATION-TYPE
Inform-Request
81
• Inform-Request behaves as trap in that the message goes from one manager to another
unsolicited
• The receiving manager sends response to the sending manager
Counter64
SNMPv2-MIB - RFC 3418
Obsoletes 1907
Yen-Cheng Chen
IM, NCNU
April, 2006
SNMPv2 SNMP MIB
82
system group { mib-2 1 }
 sysDescr
 sysObjectID
 sysUpTime
 sysContact
 sysName
 sysLocation
 sysServices
Object Resources
83
- describe the SNMP entity's support of various MIB modules.

 sysORLastChange
 sysORTable
 sysOREntry
 sysORIndex
 sysORID
 sysORDescr
 sysORUpTime
sysORTable Example
snmp group { mib-2 11 }
 snmpInPkts
 snmpInBadVersions
 snmpInBadCommunityNames
 snmpInBadCommunityUses
 snmpInASNParseErrs
 snmpSilentDrops
 snmpProxyDrops
 snmpEnableAuthenTraps
 snmpSetSerialNo
Object Types for SNMPv2 Traps
84
Notification Types
coldStart, warmStart
authenticationFailure
LinkDown, LinkUp (RFC 2233)
85
86
V UNIT - SNMP Management: RMON
What is Remote Monitoring?
Monitoring the network involves sniffing every packet going across a LAN, opening
it,and analyzing it. It is a passive operation and does nothing to the packets, which continue on to
their destinations. The device that performs this function is called a network monitor(or probe).
The monitored information, gathered and analyzed locally, can be transmitted to a
remote network management station. In such a case remotely monitoring the network with a
probe (monitor) is referred to as Remote Network Monitoring(RMON).
Figue 8.1 shows an FDDI backbone network with a local Ethernet LAN. The network
management system(NMS) is on the local Ethernet LAN.
Either an Ethernet probe or an RMON is on the Ethernet LAN monitoring the local
LAN. The FDDI backbone is monitored by an FDDI probe via the bridge and Ethernet LAN. A
87
token ring probe monitors the token ring LAN. It communicates with the network management
system via the routers, the WAN, and the backbone network.
The remote FDDI is monitored by the built-in probe on the router. The FDDI probe
communicates with the network management system. All four probes that monitor the four LANs
and communicate with the network management system are RMON devices.
RMON SMI and MIB
The Remote Network Monitoring Management Information Base (RMON MIB), which
defines RMON groups, has been developed in three stages.
The original RMON MIB , now referred to as RMON1, was developed for the Ethernet
LAN in November 1991[RFC 1271], but it was made obsolete in 1995 [RFC 1757]. Token ring
extensions to RMON1 were developed in September 1993[RFC 1513].
88
The use of RMON1 for remote monitoring was extremely beneficial, but RMON1
addressed parameters at the OSI layer 2 only. Hence RMON2[2021] was developed and released
in January 1997; it addressed the parameters associated with OSI layers 3-7.
The RMON group is node 16 under MIB-II (mib-2 16). All the groups in the overall
RMON group are shown in Figure 8.2. The overall group consists of nine Ethernet RMON1
groups (rmon1-rmon9), one token ring extension group to RMON1 (rmon10), and ten RMON2
groups (rmon11-rmon22) for the higher layers.
RMON1
RMON1 is covered by RFC 1757 for Ethernet LAN and by RFC 1513 for extensions to
token ring LAN. Two data types were introduced , as textual conventions,along with ten MIB
groups(rmon1-rmon10).
RMON1 Textual Conventions
Two new data types defined in the RMON1 Textual Conventions were OwnerString
and EntryStatus.
The owner identification is made part of the control table defined by the OwnerString
data type. The OwnerString is specified in the NVT ASCII character set as DisplayString. The
information content of OwnerString contains information about the owner, such as IP address,
management station name, network manager’s name, location or telephone number.
The EntryStatus is used to resolve conflicts that might arise between management
systems in the manipulation of control tables. The EntryStatus data type can exist in one of four
states: (1) valid, (2) createRequest, (3)underCreation, and (4)invalid. These four states are shown
below (Table 8.1).:
RMON1 Groups and Functions
RMON1 performs numerous functions at the data link layer. Figure 8.3 depicts the
RMON1 groups and functions.
The data gathering modules which are LAN probes, gather data from the remotely
monitored network comprising Ethernet and Token ring LANs. The host and conversation
89
statistics group deals with traffic data associated with the hosts, ranking the traffic for the top N
hosts, and conversation between hosts.
Figure 8.3 RMON1 Groups and Functions
The group of statistical data associated with Ethernet LAN- namely Ethernet statistics
and Ethernet history statistics- is addressed by the groups and functions in the Ethernet statistics
box. The history control table controls the data to be gathered from various networks. It is also
used by the token ring statistics module in the token ring statistics box.
The outputs of the various modules are analyzed and presented in tabular and graphical
forms to the user by the network manager in the network management system.
The filter group is a cascade of two filters. The packet filter filters incoming packets by
performing a Boolean and/or XOR with a mask specified. The output of the filter group can be
stored in the packet capture module for further analysis by the network manager.
The functions associated with the various groups are performed by ten groups
associated with the RMON1 MIB, as is shown in Table 8.2.
The first nine groups are applicable to common data and to the Ethernet LAN, and the
tenth group extends it to the token ring LAN: most of the groups have one or more tables.
90
91
The groups fall into three categories, the largest of which is the category of statistics
gathering groups. These are the statistics groups, history groups, host group, host Top N group,
and matrix group.
The second category deals with the network event reporting functions. These are the
alarm group and the event group.
The third category deals with filtering the input packets according to selected criteria
and capturing the data if desired for further analysis. These are the filter group and the packet
capture group.
In the tables column in Table 8.2 some of the groups have tables with “2’ as part of the
name. These are additional tables created during RMON2 specifications development and are
enhancements of RMON1.
Relationship between Control and Data Tables
The data table contains rows (instances) of data. The control table defines the instances
of the data rows in the data table and can be set to gather and store different instances of data.
The generic relationship between control and data tables is shown in Figure 8.4.
The value of the dataIndex in the data table is the same as the value of controlIndex in
the control table. The control index is an integer uniquely identifying the row in the control table.
The controlTableSize identifies the entries associated with this data source. The controlOwner
columnar object is the entity or person that created the entry.
To identify a unique conceptual row in the data table, we may need to specify more
indices than the dataIndex, as indicated by dataAddlIndex in Figure 8.4.
92
RMON Token Ring Extension Groups
Table 8.3 presents the token ring MIB groups and tables. Each of the eight groups has a
data table and two have control tables. There are two token ring statistics groups, one at the
MAC layer (the token ring statistics group) and the other on packets collected promiscuously
(the token ring promiscuous statistics group). Both contain statistics on ring utilization and ring
error statistics.
The MAC layer statistics group collects data on token ring parameters(e.g., token
packets, errors in packets,bursts, polling, etc.). The promiscuous statistics group collects statistics
on the number of packets of various sizes and the type of packets-multicast or broadcast data.
There are two corresponding history statistics groups: current and promiscuous. One
data table is associated with each of the four statistics groups. The history control table is
common to both Ethernet and token ring. Three groups are associated with stations on the ring.
RMON2
93
RMON1 dealt primarily with data associated with the OSI data link layer. The success
and popularity of RMON1 led to the development of RMON2[RFC 2021].
The RMON2 Management Information Base
The architecture of RMON2 is the same as that of RMON1. The RMON2 Management
Information Base (MIB) is arranged in ten groups. Table 8.4 shows the RMON2 MIB groups and
tables.
RMON2 Conformance specifications
94
Conformance specifications were not specified in RMON1, but they have been added in
RMON2. As shown in Figure 8.6, the RMON2 conformance group consists of two subgroups:
rmon2MIBCompliances and rmon2MIBGroups.
The compliance requirements are separated into basic RMON2 MIB compliance and
application layer RMON2 MIB compliance. Each compliance module defines mandatory and
optional groups. Vendors are required to implement the mandatory groups; optional groups may
be used by the vendors to specify additional capabilities.
The thirteen groups in rmon2MIBGroups are listed in Table 8.5, along with the
mandatory(M) and optional(O) requirements for basic and application level conformance to
RMON2.
95
The rmon1EnhancementGroup is mandatory for systems that implement RMON1 with

RMON2.
ATM Remote Monitoring
IETF RMON MIBs have been extended to perform traffic monitoring and analysis for
ATM networks.
Figure 8.7 shows the RMON MIB framework for the extensions, as portrayed by the
ATM Forum. Switch extensions for RMON and ATM RMON define RMON objects at the
“base” layer, which is is the ATM layer. ATM protocol IDs for RMON2 define additional objects
needed at the higher levels [RFC 2074].
96
Four different collection perspectives are possible for ATM RMON, as shown in Figure
8.8.
97
Figure 8.8(a) shows a stand-alone probe attached to a single port of a switch, and ATM
traffic is copied somehow to the RMON probe. Figure 8.8(b) shows an embedded probe within a
switch but with no access to the switch fabric; again ATM traffic is somehow copied to the
RMON probe. Figure 8.8 (c) shows an embedded probe with access to the switch fabric. Figure
8.8(d) shows a stand-alone probe, tapping a network-to-network interface between two switches.
The ATM RMON MIB is under the experimental node of the IETF Internet MIB, as
shown in Figure 8.9
The functions of the groups and the tables in each group are given in Table 8.6. The
MIB contains four groups: portSelect, atmStats, atmHost, and atmMatrix.
98
A Case Study of Internet Traffic Using RMON
At the Georgia Institue of Technology a study was undertaken, for planning purposes,
to gather statistics on Internet growth. Technical objectives of the study were to analyze (1) the
traffic growth and trend and (2) traffic patterns.
99
What was learned:

1. The three top groups of users contributing to 84% of the Internet traffic were
studentd(surprise!), newsgroups services, and domain1.
2. The growth rate of Internet use during the study period(spring quarter) was 50%.
100
VI UNIT - Telecommunications Management Network
Introduction
Management of telecommunications networks was developed by the International

Standards Organization as part of ISO management. Hence it is strongly based on ISO network
management, which in turn is based on the Common Management Information Protocol(CMIP)
and Common Management Information Services(CMIS).
In 1986, the International Telecommunications Union-Telecommunications (ITU-T)
proposed the concept of a Telecommunications Management Network(TMN) to address the
interoperability of multivendor equipment used by service providers and to define standard
interfaces between service provider operations. In addition, it also extended the concept of
management to include not only the management of networks and network elements, but also the
service functions of the service providers. It was envisioned as a solution to the complex
problems of operations, administration, maintenance, and provisioning (OAM&P) for
telecommunications networks and services.
Why TMN?
Historically, TMN was born of necessity to extend the private and proprietary- but well-
developed network management systems- and make them interoperable. TMN was the only
framework that addressed not only the management of network elements, but also the
management of networks, services, and business. The resolution of these issues is crucial in
today’s business environment with its numerous network and service providers. Customer
service, quality, and cost form a three-legged stool.
Although TMN was based on OSI management principles, it can be implemented- as is
now being done- using other management technology, such as SNMP management.
Organizations such as the NMF are promoting alternative approaches.
Operations Systems
In the early days, the large telecommunications companies referred to the systems that
maintained the network and network elements as operations systems. The TMN is built on the
foundation of the operations support system (operations system in the telephone industry). The
OS (Operations system) does not play a direct role in information transfer, but it does help in the
OAM&P of network and information systems. Two examples of OSs used in the operation of
telephone networks and services are the trunk test system and traffic measurement system.
The trunk test system, illustrated in Figure11.1, is used to monitor the loss and signal-to-
noise ratio in the trunk transmission system. A trunk is a logical entity that links two switching
offices. The transmission test system can seize any available cable facility between the switches
while not carrying traffic.
101
To ensure quality of service, losses and the signal-to-noise ratio on the trunks are
measured at regular intervals by accessing from a centralized test center every trunk at each
switching office. Any trunk that fails to meet minimum quality control criteria is removed from
service. When a trunk is taken out of service as it is failing, the customer does not experience any
degradation of service. The same test systems are used for on-demand tests to track troubles.
Careful planning and implementation of facilities adequate to handle the traffic avoid
delays and blockages. The traffic measurement operations system, illustrated in Figure 11.2,
measures the busy status of switch appearance (access point) on each switch. As the number of
busy paths increases, either owing to lack of access points or lack of adequate trunk facilities,
additional equipment is added to avoid blockages.
Figure 11.2 Operations System for Traffic measurement
TMN Conceptual Model
From a TMN point of view, the network management system (NMS) is treated as an
operations system, as shown in Figure 11.3.
102
The telecommunications network shown consists of switching exchange and transmission

system network elements. It is primarily the WAN of communications. The switching systems
contain both analog and digital and include all transport facility modes, including twisted pair,
coaxial, fiber optics, and wireless.
The data communications network components consist of LANs, bridges, routers,
gateways, and hosts. The workstation shown in Figure 11.3 attached to the data communication
network is a distinct element of TMN. The TMN shown is a network in its own right, not just
management of telecommunications network. It is TMN and not TNM.
ITU-T Recommendation M.3010 defines TMN as a conceptually separate network that

interfaces with one or more individual telecommunications networks at several points in order to
send or receive information to or from them and control their operation.
Figure 11.4 shows the TMN conceptual model. The two columns in the figure show the
identical components of two service providers A and B. These components are workstations,
OSs, networks, services, interfaces, operators of the systems, and customers who use the service.
Customers buy service from service providers, and providing quality customer services
should be a key part of a service provider’s business. The service provider tells
telecommunication services to customers, which means that the telecommunications network
needs to be operated efficiently and economically. Service management, business management,
and network management can all be accomplished, partially or totally, by using the OSs in
Figure 11.4.
103
Figure 11.4 The TMN Conceptual model
System operators interface with the OSs via workstations. The interfaces associated with
the various functions and services have been standardized in the TMN model. Notice the three
interfaces- Q3, F, and X. Q3 is the interface between an operations system and a network
element. F is the interface between a workstation and an operations system. Information
exchange between operations systems within a TMN is accomplished with the Q3 interface,
whereas OSs belonging to different TMNs communicate via the X interface.
TMN standards
The ITU-T is the standards body that developed TMN standards, based on the OSI
framework. The scope of the TMN recommendations is summarized in Figure 11.5 [NMF]. The
ITU-T document M.3000 presents a TMN tutorial. The other documents in the M series address
TMN architecture, methodology, and terminology. The Q series addresses the Q interface (e.g.,
Q3) and G.733, the protocol profile for the Q interface.
TMN documents are listed in Table 11.1, and some of the ITU-T study groups
responsible for various TMN activities are listed in Table 11.2. Supporting documents are also
shown in Figure 11.5. Network traffic management, maintenance, and security are covered in the
E and M series documents. The communication protocol, CMIP, and service elements, the
Common Management Information Service Element (CMISE) are covered in the I and X series
documents.
104
TMN documents define two types of telecommunications resources; managed and

operations systems and interfaces between them. Architectural definitions of the communications
TMN entities, their roles in TMN, and their interrelationships are described in M.3010. The
common services of OAM&P functions are defined in M.3200. The functions associated with
individual TMN management services are described in the M.3200 series. A generic set of TMN
management functions, based on OSI management functional areas, is specified in M.3400.
Management application messages and information models to support OAM&P
requirements are specified in the M.3100 series and G.774. A generic network information model
is defined in M.3100; it addresses common solutions for the management of network resources
such as switching, transmission, and other technologies. OSI management services and Common
Management Information Services (CMIS) are defined in X.710.TMN-related messages are
contained in the information model defining application protocols and support objects, which are
covered in Q-series documents.
Communication protocols are addressed in the respective protocol-specific standards
documents. The G series addresses those not covered there but that are relevant to TMN, such as
SDH network management in G.784.
TMN architecture
TMN architecture is defined in M.3010, which describes the principles for a TMN. Three
architectural perspectives are presented: functional, physical, and information, as shown in
Figure 11.6.
The functional architecture identifies functional modules, or blocks, in the TMN
environment, including the reference points between them, and specifies interface requirements.
The physical architecture defines the physical blocks and interfaces between them. The
information architecture deals with the information exchange between managed objects and
management systems, using a distributed object-oriented approach.
Functional architecture
TMN Recommendation M.3010 defines TMN architectures as five function blocks:

operations systems, network element, mediation, workstation, and Q adapter, as shown in Figure
11.7. Each function block contains a set of functions, and there are multiple instances of each
function.Communication between function blocks is itself a function, but not a function block,
and is defined as the TMN data communication function (DCF), which supports the standard
transport protocols.
105
The TMN operations systems function (OSF) is implemented in operations systems. The
TMN network element function (NEF) is concerned with managed network elements. Network
elements providing information for management (e.g., packets dropped, collision rate, etc.) are
considered to be part of TMN (i.e., NEF). The TMN mediation function (MF) block addresses
the operations performed on the information content passing between the network elements and
OSs. The TMN workstation function (WSF) provides an interface between human personnel and
TMN activities.
Communication among the four functional blocks- OSF, WSF, MF, and NEF- is assumed
to be standardized. In order to accommodate legacy functionality as part of TMN, a TMN Q
adapter function (QAF) has been defined. Function blocks are designed to be nonoverlapping.
The function blocks in Figure 11.7 are connected with interfaces denoted by x, q3, qx, and f.
They are called TMN service interfaces, or simply TMN interfaces.
The TMN interface between function blocks, shown in Figure 11.8, is called a TMN
reference point. A reference point can be considered to be a conceptual point of information
exchange between function blocks. Some examples of network devices implementing TMN
functional components are operations systems, a network management system, applications, a
network element, a management network agent, a management information base, an RMON, a
proxy server, a GUI, and a Web browser.
106
The information exchange across TMN reference points can be classified as q-class, f-
class, and x-class. The q-class reference point interfaces with a management application function.
An f-class TMN reference is an interface between the workstation function block and any other
function block in TMN. An x-class TMN reference point is an interface between two OS
function blocks belonging to two different TMNs. TMN reference points are designated by the
lowercase letters q, f, and x. The associated physical interfaces are identified by the uppercase
letters Q, F, and X.
Physical Architecture
ITU-T recommendation M.3010 presenting a model for the TMN physical architecture is
illustrated in Figure 11.9.
Figure11.9 TMN Physical Architecture
The Q,F, and X TMN interfaces between the physical devices are also shown in
Figure11.9, representing the physical implementation of the respective TMN reference points.
The Q3 interface is used between the OS and an NE or a QA. The Qx interface is used between
an MD and a QA or an NE. The F interface is implemented to connect a workstation to TMN.
The X interface is used between OSs belonging to two different TMNs.
Information Architecture
The TMN information architecture initially adopted the OSI management information
architecture, CMIP/CMIS, defined in the ITU-T X.700 series. OSI information model is object-
107
oriented, and the SNMP model is scalar. Both models are based on the dual roles that entities
play in information exchange; manager and agent. Figure 11.10 shows the information exchange
between the two types of entities.
The manager performs operations or makes requests from an agent. The agent executes
the operations on the network elements that it is managing and sends responses to the manager.
The agent also sends unsolicited messages to the manager indicating alarm events. Information
models specified by SNMP and OSI management deal with the management of network
elements. The information architecture should support information reliably across functional
boundaries.
There are two types of communication services between interfaces: interactive and file-
oriented. The interactive category is supported in OSI by the Common Management Information
Service Element (CMISE) over the Remote Operations Service Element (ROSE). The file-
oriented category is supported by File Transfer Access Management (FTAM) in OSI and on the
Internet by the File Transfer Protocol (FTP). In the OSI model, the Association Control Services
Element (ACSE) is needed to establish, release, and abort application associations. In the
Internet model, it is integrated into the RPC presentation service.
TMN Management Service Architecture
Another functional model of TMN is based on the services provided in a TMN

environment. The TMN services are grouped and presented as TMN layered architecture, as
shown in Figure 11.11[ITU-T, M.3400].
108
The lowest layer is the network element layer, comprising network elements, such as
switches, routers, bridges, and transmission facilities. The second layer is the element
management layer, which manages the network elements. The third layer is the network
management layer, which manages the network. The network management functions in this layer
include bandwidth, performance, quality of service, end-to-end flow control, and network
congestion control.
The service management layer is concerned with managing the services provided by a
network service provider to customers or to other network service providers. They include
services such as billing, order processing, complaints, and trouble ticket handling. The top layer
is the business management layer. It is concerned with managing the operations of a
communications business, including fiscal considerations, human resource needs, project
management, and customer needs and satisfaction.
The reference point between the various service layers is q3. TMN management services
are classified by OSI system management functional area. These areas are the five OSI
application functions:configuration management, fault management, performance management,
security management, and accounting management. The TMN management services and the
system management functional areas are presented in Figure 11.12.
Figure 11.12 TMN Management Services and Management Functional Areas
109
An Integrated View of TMN
A representation of the view of how the various aspects of the TMN architecture fit
together is shown in Figure 11.13. The four TMN management services are at the top of the
hierarchy. They invoke the system management functions defined as the five components
comprising the system management functional areas: configuration, fault, performance, security,
and accounting.
The management applications in the system functional areas perform either system
management functions or TMN functions. The system management functions include object
management and alarm management. System management functions and TMN functions invoke
the primitive services.
Figure 11.13 also shows the OSI primitive services of M-GET, M-SET, and so on. The
TMN environment is a distributed environment. The applications communicate remotely with
the communication transport service by means of the RPC. In the OSI model, the RPC is
accomplished with ROSE and ACSE. The former does the remote operation and the latter
establishes and releases the application association.
110
Implementation issues
Although the TMN concept was proposed in the early 1980s, it has not been widely
accepted for several reasons. These reasons include heavy dependence on exclusive OSI network
management, high resource requirements, technical complexity, lack of complete standards, the
popularity and simplicity of SNMP management, and implementation difficulties.
OSI toolkits are currently available both commercially and as freeware. As a result of
these advances, products have been developed recently for trouble ticket administration (TMN X
interface) and the integrated digital loop carrier (TMN Q3 interface). Recent advances in
hardware and technology have revived work on the distributed management environment, using
an object-oriented approach.
Two forums have actively promoted implementation of TMN: the ATM Forum and NMF
(formerly known as the Network Management Forum).
Implementation Using OMNIPoint:
An example of TMN architecture realization is presented in Figure 11.14 [NMF]. Figure

11.14(a) shows the TMN logical layered architecture and Figure 11.14(b) shows a physical
realization of it. Each layer consists of several management systems that provide the various
services. The layered architecture shows the TMN q3 reference points, and the physical
realization shows the corresponding Q3 interfaces.
111
The NMF is an industry-sponsored forum. It has developed a program called the Open
Management Interoperability Point (OMNIPoint). The objective is to help companies implement
management standards for a broad range of supplier’s equipment. It has developed documents
that specify mapping between the Internet and OSI standards to help TMN implementation in a
hybrid management environment [NMF].
112
UNIT VII
NETWORK MANAGEMENT TOOLS AND SYSTEMS
Network Management Tools are necessary for troubleshooting of problems in networks

and supplement system tools that detect problems or failures and notify the various alarms.
Network managers and operators use these tools daily to conduct their activities. Some of these
tools can also be utilized by network users in their normal use of network services.
Tools Catalog
A tools catalog listing the tools available in 1993 was generated by the IETF working
group on Network Operations Center tools (NOCtools) [RFC 1470].Updates are available via the
Web sources news:comp.networks.noctools and ftp://wuarchive.wustl.edu/doc/noctools.
Categories of tools are listed in RFC 1470.
Under the functional category, the keyword Alarm identifies a reporting/logging tool that
can be triggered by specific events within a network, such as the NetMetrixTM Protocol
analyzer.
On UNIX systems, the file /etc/hosts is used to hold the network addresses, as well as one
special connection called the loopback (which is examined later in this chapter in the section
titled "The Loopback Driver"). The loopback connection address is usually listed as the machine
name loopback or localhost.
The file /etc/hosts consists of the network address in one column separated from the
symbolic name in another. The network addresses can be specified in decimal, octal, or
hexadecimal format (although decimal is the most common). More than one symbolic name can
be specified on a line by separating the names with either space characters or tabs. The /etc/hosts
file can be as long as necessary to contain all the symbolic names used on the local machine;
they do not need to be presented in any order. A sample UNIX /etc/hosts file is as follows:
# network host addresses
127.0.0.1 localhost local tpci_server
157.40.40.1 tpci_sco1
157.40.40.2 tpci_sco2
157.40.40.3 tpci_hpws1
157.40.40.0 tpci_server tpci_main tpci
47.80.157.36 bnr.ca BNR bnr
191.13.123.4 kitty_cat
205.150.89.1 roy_maclean big_roy
113
210.24.47.128 bobs_machine
As you can see, the file is made up of two columns. The first column gives the IP address
of a machine, and the second (separated by one or more whitespace characters) gives the
machine's name. If several names can be used to identify the remote machine, they are listed on
the same line, separated by whitespace. For example, the remote machine with IP address
205.150.89.1 can be addressed as either roy_maclean or big_roy. Whenever either of those
names is used in a command (such as an FTP or Telnet application), this file is used to match to
the proper IP address.
A system or network administrator can update the /etc/hosts file at any time, and changes
are effective immediately (so the machine doesn't have to be rebooted to effect the changes).
Whenever a symbolic name is specified by a user or an application, the /etc/hosts file is always
searched first for a matching name, and the proper address is read from the same line.
Most TCP/IP implementations on other platforms have a similar type of file to resolve IP
addresses from symbolic names. NetManage ChameleonNFS running on a Windows 3.x
machine, for example, uses a Host Table to match names and IP addresses.
Networks can be addressed by a symbolic name, just as machines are. To resolve the
network names, another file is used that contains the corresponding network address. Typically,
this file isn't accessed often, because few users want to address an entire network within their
application. The network name resolution file's most common use is to specify the local
network's name.
UNIX systems usually use the file /etc/networks to specify symbolic network names. The
format of the file provides a network symbolic name, its network address, and any alias that
might be used, in much the same format as the /etc/hosts table is used for specific machines. A
sample /etc/networks file is shown here:
# local network names
tpci 146.1 tpci_network tpci_local
bnr 47.80 BNR bnr.ca
tmn 123.2.21
unique 89.123.23 UNIQUE
sco 132.147 SCO
loopback 127 localhost
The /etc/networks file layout is a little different from /etc/hosts in that the usual network
name is given in the first column, followed by the IP network address, then any aliases. The last
entry in this example file gives the loopback name. The first entry specifies the local machine
name, its network address, and any name variants. Using this file, an application that wanted to
reach the network called UNIQUE could use that name and let the operating system resolve it to
the IP network address 89.123.23.
Many implementations of TCP/IP on other platforms don't bother with a network name
resolution file like this. Part of the reason is that the /etc/networks file has little use on a UNIX
114
platform, and many single-user operating systems don't require the type of versatility a multiuser
operating system like UNIX must supply to an entire network.
Protocol numbers are used to identify the transport protocol to the receiving machine to enable
proper decoding of the information within the datagram. With TCP/IP, the protocol number is
embedded in the Internet Protocol header. A configuration file is usually used to identify all the
transport protocols available on the system and their respective protocol numbers.
UNIX systems use the /etc/protocols file for this purpose. Usually, this file is not
modified by the administrator but is maintained by the system and updated automatically as part
of the installation procedure when new TCP/IP software or services are added. The /etc/protocols
file contains the protocol name, its number, and any alias that might be used for that protocol. A
sample /etc/protocols file is shown here:
#
# Internet (IP) protocols
ip 0 IP # internet protocol, pseudo protocol number
icmp 1 ICMP # internet control message protocol
igmp 2 IGMP # internet group management protocol
ggp 3 GGP # gateway-gateway protocol
tcp 6 TCP # transmission control protocol
egp 8 EGP # Exterior-Gateway Protocol
pup 12 PUP # PARC universal packet protocol
udp 17 UDP # user datagram protocol
hello 63 HELLO # HELLO Routing Protocol
ospf 89 OSPF # Open Shortest Path First Routing Protocol
In this /etc/protocols file, the IP protocol is assigned protocol 0, and TCP is protocol 6.
The values in this table should not be changed from their default values except when special
network conditions mandate a change. If new TCP/IP services are added to the UNIX system this
file resides on, new entries are made to this file by the application installation routine.
There are usually no equivalents of the /etc/protocols file on other operating systems
because they assume that the standard transport number is used for each protocol.
Network Services: /etc/services
The final common configuration file used on most UNIX systems identifies the existing
network services. As with the /etc/protocols file, this file is not usually modified by an
administrator but is maintained by software as it is installed or configured.
115
The UNIX network services file is /etc/services. The file is in ASCII format consisting of
the service name, a port number, and the protocol type. The port number and protocol type are
separated by a slash. The port numbers for TCP/IP usually follow the conventions mentioned in
the previous chapters. Any optional service alias names follow after the port numbers. A short
extract from a sample /etc/services file (the file is usually quite lengthy) is shown here:
# network services
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail mailx
tftp 69/udp
# specific services
login 513/tcp
who 513/udp whod
TCP/IP requires that each machine on the network have an IP address. Usually, each
machine also has a unique symbolic name; otherwise, the IP address must be used for all
connections to that machine. Most operating systems have a simple program that identifies the
name of the local machine. UNIX systems have the utility hostname for this purpose, as well as
the uname program, which can give the node name with the command uname -n. The uname
utility is usually supported in System V and compatible operating systems only.
The host name is sometimes saved in a separate file that is read when the operating
system starts up, or it can be read from one of the configuration files mentioned previously. The
hostname is used by most protocols on the system and by many TCP/IP applications, so it is
important for proper system operation. The host name can sometimes be changed by editing the
system file that contains the name and then rebooting the machine, although many operating
systems provide a utility program to ensure that this process is performed correctly.
On many UNIX systems, the hostname and uname commands echo back the local
machine name, as the following sample session shows:
$ hostname
tpci_sco4.tpci.com
$ uname -n
116
tpci_sco4
On the SCO UNIX system used in this example, the hostname command returns the fully
qualified domain name, whereas the uname command provides the local machine name only. On
a Hewlett-Packard workstation running HP-UX, both commands return only the local machine
name. The exact behavior of the hostname and uname commands is therefore quite dependent on
the implementation.
On a Linux system, for example, the hostname command can be used to not only show
the current host name setting but also to change it when used with the -S (for set) option. For
example, the command
hostname -S willow.tree.com
changes the local fully qualified domain name to willow.tree.com. Not all versions of Linux
support the -S option of the hostname command.
Most TCP/IP suites for other operating systems use a simpler method of setting the host
name. For example, on a Windows 3.x machine the NetManage ChameleonNFS package uses the
dialog shown in Figure 7.2 to quickly set the host name.
Windows NT has TCP/IP services built into the basic distribution. On a Windows NT
system, the host name is specified through the Network dialog opened from the Control Panel.
Both the Windows NT and Windows 3.x systems enable a change in the host name to be made
effective immediately, although a system reboot is recommended to clear all configuration
information held in memory.
A potential problem can occur when the local machine is multihomed, or based in several
networks with a different name and IP address for each network. The single name in the
configuration file in such an installation might not provide enough information to permit proper
routing over all the connected networks. This problem is seldom encountered, but it does require
the system administrator to set the hostname for each network carefully.
Aside from the simple machine name query shown, the hostname system is a full
protocol that enables access to the Network Information Center (NIC) tables to verify addresses
and obtain information about the network, gateways, and hosts. It uses TCP port number 101 to
connect to the NIC. This type of access is usually restricted to the network administrator.
Using the loopback driver to reroute the output stream, the network interface card
(usually an Ethernet card) is bypassed. The loopback driver is useful for testing TCP/IP software
installations, because it immediately shows any problems with the local configuration. This can
be done before the machine is physically connected to the network or even before the networking
hardware and software are installed. For example, you can use the loopback driver to test your
TCP/IP configuration before it is connected to a network by using the ping command with the
localhost name or IP address, as the following example shows:
# ping -c5 localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64 time=10 ms
117
--- localhost ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0/2/10 ms
# ping -c5 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
round-trip min/avg/max = 0/0/0 ms
In the preceding example I used the ping command with the -c option to specify five
pings, first with the localhost name (which /etc/hosts resolves to the IP address 127.0.0.1) and
then with the IP address itself. If either command had failed, it would indicate a problem with
either the /etc/hosts file (if the name localhost could not be resolved) or with the TCP/IP
installation (if both commands failed).
Managing ARP
The arp program manages entries in the system's Address Resolution Protocol (ARP)
tables. You may recall that ARP provides the link between the IP address and the underlying
physical address. For more information, see Day 2, "TCP/IP and the Internet."
Using arp (or its equivalent in other operating systems), the administrator can create, modify, or
delete entries in the ARP table. Typically, this has to be performed whenever a machine's
network address changes (either because of a change in the network hardware or because of a
physical move).
The arp program differs considerably between implementations and is seldom used by
users, so examples of its use are left to the operating system's configuration and administration
documentation.
Using ifconfig
118
The ifconfig program, or one like it, enables an administrator to activate and deactivate
network interfaces, as well as to configure them. Access to the ifconfig program is generally
restricted to a superuser or network administrator. Changes to the configuration can usually be
made only before the system is fully operational (such as in single-user mode on a UNIX
system). When issued, ifconfig essentially instructs the network layer of the kernel to work with
the specified network interface by assigning an IP address, then issuing a command to make the
interface active on the system. Only when the interface is active can the operating system kernel
send and receive data through the interface.
The ifconfig program enables a network administrator to perform several useful functions on
most operating systems:
Activate or deactivate an interface
Activate or deactivate ARP on an interface
Activate or deactivate debugging mode on an interface
Assign a broadcast address
Assign a subnetwork mask
Assign a routing method
Examining all the options available to ifconfig would require several dozen pages.
Because this material is rarely used and differs with each implementation, administrators are
referred to their operating system documentation. As an example, the Linux version of the
ifconfig command uses this general format:
ifconfig interface_type IP_Address
interface_type is the interface's device driver name (such as lo for loopback, ppp for PPP,
and eth for Ethernet), and IP_Address is the IP address used by that interface.
When used with only the name of an interface, ifconfig usually returns information about the
current state of the interface, as shown in the following example. In this example, a query of both
an Ethernet card (called ec0) and the loopback driver (called lo0) is performed. The status flags
of the interface are followed by the Internet address, the broadcast address, and optionally a
network mask, which defines the Internet address used for address comparison when routing.
tpci_sco1-12> ifconfig ec0
ec0: flags=807<UP,BROADCAST,DEBUG,ARP>
inet 146.8.12.15 netmask fffff00 broadcast
146.8.12.15
tpci_sco1-13> ifconfig lo0
lo0: flags=49<UP,LOOPBACK,RUNNING>
inet 127.0.0.1 netmask ff000000

The preceding example shows that the Ethernet connection ec0 is active (UP), able to transmit
broadcasts (BROADCAST), and is in debugging mode (DEBUG). Also, the ARP protocol is
119
active (ARP). You may recall that a broadcast message is sent to all machines on the local
network by setting the host ID address to all 1s.
Once the ifconfig command has been run and an interface is active, many operating
systems require the route command to be issued to add or remove routes in the kernel's routing
table. This is needed to enable the local machine to find other machines. The general format of
the route command on a UNIX or Linux system is this:
route add|del IP_Address
Either add or del is specified to add or remove the route from the kernel's routing table,
and IP_Address is the remote route being affected.
The current contents of the kernel's routing table can be displayed on some systems by entering
the command route by itself on the command line. For example, on a Linux system that is set up
only with the loopback driver, you see an output like this:
$ route
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use Iface
loopback * 255.0.0.0 U 1936 0 16 lo
The important columns are the destination name, which shows the name of the
configured target (in this case only loopback), the mask to be used (Genmask), and the interface
(Iface, in this case /dev/lo). You can force route to display the IP addresses instead of symbolic
names by using the -n option:
$ route -n
Kernel Routing Table
Destination Gateway Genmask Flags MSS Window Use Iface
127.0.0.1 * 255.0.0.0 U 1936 0 16 lo
Not all UNIX and Linux versions show this type of output from the route command. The
use of the ifconfig and route programs can be shown in the setup of a Slackware Linux system's
Ethernet connection. To make the Ethernet interface active, the ifconfig command is issued with
the Ethernet device name (eth0 on a Slackware Linux system) and the local IP address. For
example, the command
ifconfig eth0 147.123.20.1
sets up the local machine with the IP Address 147.123.20.1. The interface is the Ethernet
device /dev/eth0. The interface can then be checked with the ifconfig command using the
interface name:
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask 255.255.255.0
120
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0

You may notice in the output that the broadcast address was set based on the local machine's IP
address. This is used by TCP/IP to access all machines on the local area network at once. The
Message Transfer Unit (MTU) size is usually set to the maximum value of 1500 (for Ethernet
networks).
Next, an entry is added to the kernel routing tables to let the kernel know about the local
machine's network address. The IP address that is used with the route command is not your local
machine's IP address, but that of the network as a whole without the local identifier. To set the
entire local are network at once, the -net option of the route command is used. In the case of the
IP addresses shown earlier, the command would be this:
route add -net 147.123.20.0
This adds all the machines on the network identified by the network address 147.123.20 to the
kernel's list of accessible machines. An alternative method is to use the /etc/networks file. Once
the route has been added to the kernel routing tables, it can be tested with the ping command.
The inetd Daemon
The inetd program is a holdover from the early days of TCP/IP UNIX development.
When a UNIX machine was started, it would activate TCP/IP and immediately accept
connections at its ports, spawning a process for each. This could result in many identical
processes, one for each available port.
To control the processes better, the inetd program was developed to handle the port
connections itself, offloading that task from the server. The primary difference is that inetd
creates a process for each connection that is established, whereas the server creates a process for
each port (which leads to many unused processes).
On many systems, some of the test programs and status information utilities are run
through inetd. Typically, services like echo, discard, and time use inetd.
The inetd program uses a configuration file usually called /etc/inetd.cfg, /etc/inetd.conf,
or /etc/inetd.cf on UNIX systems. An extract of a sample /etc/inetd.cfg file is shown in the
following code:
# @(#)inetd.conf 5.2 Lachman System V STREAMS TCP source
# System V STREAMS TCP - Release 4.0
ftp stream tcp nowait NOLUID /etc/ftpd ftpd
telnet stream tcp nowait NOLUID /etc/telnetd telnetd
shell stream tcp nowait NOLUID /etc/rshd rshd
login stream tcp nowait NOLUID /etc/rlogind rlogind
121
exec stream tcp nowait NOLUID /etc/rexecd rexecd
finger stream tcp nowait nouser /etc/fingerd fingerd
comsat dgram udp wait root /etc/comsat comsat
ntalk dgram udp wait root /etc/talkd talkd
echo stream tcp nowait root internal
discard stream tcp nowait root internal
chargen stream tcp nowait root internal
daytime stream tcp nowait root internal
time stream tcp nowait root internal
echo dgram udp wait root internal
discard dgram udp wait root internal
chargen dgram udp wait root internal
daytime dgram udp wait root internal
time dgram udp wait root internal
The columns show the service name (which corresponds to an entry in the services file,
such as /etc/services), the socket type (stream, raw, or datagram), the protocol name, whether
inetd can accept further connections at the same port immediately (nowait) or must wait for the
server to finish (wait), the login that owns the service, the server program name, and any optional
parameters needed for the server program.
The configuration file is read when the server is booted and every time a hang-up signal
is received from an application. This enables dynamic changes to the file, because any
modifications would be read and register on the next file read.
The netstat Command
The netstat program or a similar utility provides comprehensive information about the
local system and its TCP/IP implementation. This is the program most commonly used by
administrators to quickly diagnose a problem with TCP/IP. The actual information and its format
supplied by the netstat utility differs with the operating system implementation, but it usually
supplies the following important summaries, each of which is covered in more detail later:
Communications end points
Network interface statistics
Information on the data buffers
Routing table information
Protocol statistics
122
On some systems, information about the interprocess communications and other protocol
stacks might be appended. The information to be displayed can usually be toggled with a
command-line option. The output from a typical UNIX installation that uses the netstat command
is shown in the next few sections, which discuss netstat and its output in more detail. The output
and meaning might be different with other operating systems, but the general purpose of the
diagnostic tool remains the same.
Communications End Points
The netstat command with no options provides information on all active communications
end points. To display all end points (active and passive), netstat uses the -a option.
The output is formatted into columns showing the protocol (Proto), the amount of data in
the receive and send queues (Recv-Q and Send-Q), the local and remote addresses, and the
current state of the connection. A truncated sample output is shown here:
$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
ip 0 0 *.* *.*
tcp 0 2124 tpci.login merlin.1034 ESTABL.
tcp 0 0 tpci.1034 prudie.login ESTABL.
tcp 11212 0 tpci.1035 treijs.1036 ESTABL.
tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT
tcp 0 0 *.1028 *.* LISTEN
tcp 0 0 *.* *.* CLOSED
tcp 0 0 *.6000 *.* LISTEN
tcp 0 0 *.listen *.* LISTEN
tcp 0 0 *.1024 *.* LISTEN
tcp 0 0 *.sunrpc *.* LISTEN
tcp 0 0 *.smtp *.* LISTEN
tcp 0 0 *.time *.* LISTEN
tcp 0 0 *.echo *.* LISTEN
tcp 0 0 *.finger *.* LISTEN
123
tcp 0 0 *.exec *.* LISTEN
tcp 0 0 *.telnet *.* LISTEN
tcp 0 0 *.ftp *.* LISTEN
tcp 0 0 *.* *.* CLOSED
udp 0 0 *.60000 *.*
udp 0 0 *.177 *.*
udp 0 0 *.1039 *.*
udp 0 0 *.1038 *.*
udp 0 0 localhost.1036 localhost.syslog
udp 0 0 *.1034 *.*
udp 0 0 *.* *.*
udp 0 0 *.1027 *.*
udp 0 0 *.1026 *.*
udp 0 0 *.sunrpc *.*
udp 0 0 *.1025 *.*
udp 0 0 *.time *.*
udp 0 0 *.daytime *.*
udp 0 0 *.chargen *.*
udp 0 0 *.route *.*
udp 0 0 *.* *.*
In the preceding example, there are three active TCP connections, as identified by the
state ESTABL. One has data being sent (as shown in the Send-Q column), and another has
incoming data in the queue. The network names and port numbers of the connection ends are
shown whenever possible. An asterisk (*) means there is no end point associated with that
address yet.
One connection is waiting to be hung up, identified by TIME_WAIT in the state column.
After 30 seconds, these sessions are terminated and the connection freed. Any row with LISTEN
as the state has no connection at the moment, and is waiting. There is no state column for UDP
sessions because they do not have an end-to-end connection (as discussed on Day 5, "Gateway
and Routing Protocols"). A CLOSED entry in the output shows that the connection is closed but
hasn’t switched over to LISTEN yet.
124
Network Interface Statistics
The behavior of the network interface (such as the network interface card) can be
determined with the -i option to the netstat command. This information quickly shows an
administrator whether there are major problems with the network connection.
The netstat -i command displays the name of the interface, the maximum number of
characters a packet can contain (Mtu), the network and host addresses or names, the number of
input packets (Ipkts), input errors (Ierrs), output packets (Opkts), output errors (Oerrs), and
number of collisions (Collis) experienced in the current sampling session. The collisions column
has relevance only for a networking system that enables packet collisions, such as Ethernet. A
sample output from a netstat -i command is shown here:
$ netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis
ec0 1500 tpci merlin 34 0 125 0 0
lan0 1497 47.80 tpci_hpws4 11625 0 11625 0 0
lo0 8232 loopback localhost 206 0 206 0 0

An administrator can obtain more specific information about one interface by using the -I option
with a device name and a time interval, specified in seconds, such as netstat -I ec0 30 to obtain
specific information about the behavior of the ec0 (Ethernet) interface over the last 30 seconds.
Data Buffers
Information about the data buffers can be obtained with the netstat command's -m option.
Monitoring the behavior of the buffers is important, because they directly impact the
performance of TCP/IP. The output of the netstat -m command differs depending on the version
of UNIX in use, reflecting the different implementations of the TCP/IP code.
The netstat -m command output from a System V-based UNIX version is shown in the
following code example. Entries are provided for the streamhead, queue, message descriptor
table (mblks), data descriptor table (dblks), and the different classes of data descriptor tables. The
columns show the number of blocks configured (config) and currently allocated (alloc), the
number of columns free (free), the total number of blocks in use (total), the maximum number of
blocks that were in use at one time (max), and the number of times a block was not available
(fail).
$ netstat -m
streams allocation:
config alloc free total max fail
streams 292 79 213 233 80 0
queues 1424 362 1062 516 368 0
125
mblks 5067 196 4871 3957 206 0
dblks 4054 196 3858 3957 206 0
class 0, 4 bytes 652 50 602 489 53 0
class 1, 16 bytes 652 2 650 408 4 0
class 2, 64 bytes 768 6 762 2720 14 0
class 3, 128 bytes 872 105 767 226 107 0
class 4, 256 bytes 548 21 527 36 22 0
class 5, 512 bytes 324 12 312 32 13 0
class 6, 1024 bytes 107 0 107 1 1 0
class 7, 2048 bytes 90 0 90 7 1 0
class 8, 4096 bytes 41 0 41 38 1 0
total configured streams memory: 1166.73KB
streams memory in use: 44.78KB
maximum streams memory used: 58.57KB

For the administrator, the failure column is important. It should always show 0s. If a larger
number appears, that resource has been overtaxed and the number of blocks assigned to that
resource should be increased (followed by a kernel rebuild and a reboot of the system to effect
the changes).
Routing Table Information
Routing tables are continually updated to reflect connections to other machines. To obtain
information about the routing tables, the netstat -r and -rs options are used. (The latter generates
statistics about the routing tables.)
The output from netstat -r and netstat -rs commands are shown in the following code
example. The columns show the destination machine, the address of the gateway to be used, a
flag to show whether the route is active (U) and whether it leads to a gateway or a machine (H
for host), a reference counter (Refs) that specifies how many active connections can use that
route simultaneously, the number of packets that have been sent over the route (Use), and the
interface name.
$ netstat -r
Routing tables
Destination Gateway Flags Refs Use Interface
localhost localhost UH 4 10 lo0
126
merlin localhost UH 2 2 ec0
treijs hoytgate UG 0 0 ec0
47.80 bcarh736 U 12 21029 lan0
tpci sco4-57> netstat -rs
routing:
0 bad routing redirects
0 dynamically created routes
0 new gateways found unreachable
2 destinations found unreachable
122 uses of a wildcard route
0 routes marked doutbful
0 routes cleared of being doubtful
0 routes deleted
Protocol Statistics
Statistics about the overall behavior of network protocols can be obtained with the netstat
-s command. This usually provides summaries for IP, ICMP, TCP, and UDP. The output from this
command is useful for determining where an error in a received packet was located, which then
leads the user to isolate whether that error was caused by a software or network problem.
Issuing the netstat -s command provides a verbose output. A sample output is shown in
the following code. The entries are self-explanatory.
tpci_sco4-67> netstat -s
ip:
183309 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with unknown protocol
127
13477 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled
0 packets forwarded
0 packets not forwardable
75 no routes
0 redirects sent
0 system errors during input
309 packets delivered
309 total packets sent
0 system errors during output
0 packets fragmented
0 packets not fragmentable
0 fragments created
icmp:
1768 calls to icmp_error
0 errors not generated because old message was icmp
Output histogram:
destination unreachable: 136
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
destination unreachable: 68
0 message responses generated
68 messages received
128
68 messages sent
0 system errors during output
tcp:
9019 packets sent
6464 data packets (1137192 bytes)
4 data packets (4218 bytes) retransmitted
1670 ack-only packets (918 delayed)
0 URG only packets
0 window probe packets
163 window update packets
718 control packets
24 resets
9693 packets received
4927 acks (for 74637 bytes)
37 duplicate acks
0 acks for unsent data
5333 packets (1405271 bytes) received in-sequence
23 completely duplicate packets (28534 bytes)
0 packets with some dup. data (0 bytes duped)
38 out-of-order packets (5876 bytes)
0 packets (0 bytes) of data after window
0 window probes
134 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 system errors encountered during processing
224 connection requests
129
130 connection accepts
687 connections established (including accepts)
655 connections closed (including 0 drops)
24 embryonic connections dropped
0 failed connect and accept requests
0 resets received while established
5519 segments updated rtt (of 5624 attempts)
5 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
0 connections lingered
0 linger timers expired
0 linger timers cancelled
0 linger timers aborted by signal
udp:
0 incomplete headers
0 bad data length fields
0 bad checksums
68 bad ports
125 input packets delivered
0 system errors during input
268 packets sent
The ping Utility
130
The ping (Packet Internet Groper) utility is used to query another system to ensure that a
connection is still active. (You may recall the ruptime utility from yesterday, which also does
this. However, ruptime waits five minutes before trying the remote, and you may want to know
right away if the connection is active.) The ping command is available on most operating
systems that implement TCP/IP.
The ping program operates by sending out an Internet Control Message Protocol (ICMP)
echo request. If the destination machine's IP software receives the ICMP request, it issues an
echo reply immediately. The sending machine continues to send an echo request until the ping
program is terminated with a break sequence (Ctrl+C or the Delete key in UNIX). After
termination, ping displays a set of statistics. A sample ping session is shown here:
$ ping merlin
PING merlin: 64 data bytes
64 bytes from 142.12.130.12: icmp_seq=0. time=20. ms
--- merling PING Statistics ---
round-trip (ms) min/avg/max = 10/12/20
An alternate method to invoke ping is to provide the number of times you want it to
query the remote. Also, you could provide a packet length as a test. The following example
instructs ping to use 256 data byte packets and try five times. Using ping to send large packets is
one method of determining the network's behavior with large packet sizes, especially when
fragmentation must occur. The ping program is also useful for monitoring response times of the
network, by observing the reply time on packets sent as the network load (or the machine load)
changes. This information can be very useful in optimization of TCP/IP.
$ ping merlin 256 5
PING merlin: 256 data bytes
131
--- merling PING Statistics ---
round-trip (ms) min/avg/max = 10/13/20
Some older implementations of ping simply reply with a message that the system at the
other end is active. (The message is of the form X is alive.) To obtain the verbose messages
shown previously, the -s option must be used.
The ping program is useful for diagnostics because it provides four important pieces of
information: whether the TCP/IP software is functioning correctly; whether a local network
device can be addressed (validating its address); whether a remote machine can be accessed
(again validating the address and testing the routing); and verifying the software on the remote
machine.
Most non-UNIX TCP/IP implementations provide ping utilities as part of their suite. For
example, Figure 7.4 shows the NetManage ChameleonNFS ping utility. The Chameleon ping
sends only a single ICMP packet instead of a continuous stream, but is useful for verifying that a
remote machine is responding.
Windows 95 has a ping utility built into the distribution software, but it is DOS-based and doesn't
use the Windows 95 GUI. Figure 7.5 shows the Windows 95 ping utility used to ping another
machine on the network.
Tracing a Connection
There is a tracing option built into TCP/IP. When simpler methods have failed, this option
can be used to trace a problem. To activate the trace, a system call is sent to the end point that
turns on a flag. Most TCP/IP implementations enable the tracing option to be turned on from the
command line using the -d (debug) option. When tracing is turned on, all activities are echoed to
a buffer or to the screen, depending on the system configuration.
The output from the TCP/IP tracing option is examined using the program trpt (trace
report). A specific connection can be specified, or all behavior passing through TCP/IP can be
displayed. The output from trpt is verbose and of little interest to most users.
132
UNIT VIII Web-Based Management
NMS with Web Interface and Web-Based Management
The Web Interface deals with how information is presented to the user (i.e., with the user
interface). For example, Big Brother and Spong use simple UNIX shell or Perl scripts to monitor
system conditions and report them periodically to a central server. This communication is based
on the TCP/IP protocol.
In its pure implementation, Web-Based management is based on Web technology. In this
configuration, the agent is embedded in the network element as a Web server and can monitor
and/or control the network element. Use of a management application and Web browser allows
the information from the Web server agent to be displayed on a Web-based display.
The Desktop Management Interface (DMI) is the standard for Web-based management of
desktops and servers. The Desktop Management Task Force (DMTF) is attempting to bring the
various management technologies under one umbrella called Web-Based Enterprise Management
(WBEM). Java applets, called Java Beans, have been extended to manage network and system
components; Sun defines them as Java Management Extensions (JMX). Java technology is also
being extended to manage distributed management storage areas. This task is being undertaken
by a consortium of Java technology users and is called the JIRO Platform.
Web-Based Management
• Display on Web browser

• Economical displays
• Ubiquitous access
• Reduction in network load for non-polled
configuration
• Web Interface vs Web-base management
• Web-based management
• Desktop management interface
• Web-based enterprise management
• Java management extensions
Web Interface to SNMP Management
Two approaches are available to implement a Web interface on existing SNMP-based

management systems. The first and short-term approach is to add a Web interface to an existing
management system. The second is to have a Web-based system with embedded Web agents in
the network components.
133
The most common implementation is to establish a Web sever on an NMS platform with
an interface to the NMS, as shown in Figure 14.1. The SNMP NMS implementation is platform
and operating system-specific, and the agents in managed objects are SNMP agents. The
protocol between the agents and the manager is the SNMP communication protocol, traversing
over UDP/IP. There is a management console for the NMS, and the Web server resides on the
same platform. The protocol between the Web server and the Web browser is HTTP, traversing
the Internet. The browser can be on any platform.
The SNMP network management systems currently on the market have only text and
tables on the Web interface. The NMS is replaced with the proxy server, and the NMS console is
eliminated which is an economic advantage. The local Web browser, becomes the NMS console
for the operations center.
Other advantage of this approach are that the proxy server can be implemented on any
platform and that the protocol between the proxy server and management agents can be either
SNMP or any proprietary protocol.
Web Interface
134
Proxy Server
Embedded Web-Based Management
In embedded Web-based management (WBM), Web servers are embedded in the

managed objects. Each managed object is assigned a Web address. The management application
receives management information from the agents and displays it by means of a Web browser, as
shown in Figure 14.3.
Web servers are more intelligent than SNMP agents, which mostly read counters and pass
information to the manager or respond to a ping. SNMP agents can send unsolicited basic traps
to the manager. For small offices, whose management requirements are minimal, the browser
could monitor the Web agents directly, without any management application software. Thus
embedded Web agents in network elements greatly simplify network management for network
administrators.
Another benefit of embedded WBM is that we can take advantage of portable tools to
write the Web agent. The Java virtual machine ( Java interpreter) is available for a variety of
platforms. The browser also is portable. The two most popular browsers, Netscape Navigator and
Microsoft’s Internet Explorer, are also available on multiplatforms.
Commercial network products with built-in Web pages are now available; but they are
based on proprietary protocols. For example, Hewlett-Packard produces Web-based management
agents in hubs and switches. Figure 14.4 shows the configuration of both Web and non-Web
agents. Web agents function and provide data much the same as RMON does. Non-Web agents
135
are managed by a Web-agent. This method is especially beneficial for two reasons. First, a
network element without a Web agent can be managed in a Web-based management
environment. Second, the configuration enables remote probing of switched LANs. A limited set
of statistical data on a non-Web managed device is collected through the Web server and
transmitted to the management application. It is limited in that no packet capturing is done.
Embedded WBM
HP Embedded Agent
136
Desktop Management Interface
Desktop Management Interface
 Industry standard generated by

o Desktop Management Task Force (DMTF)
 Started in 1992 to manage PCs
 Manages both hardware and software
 Two standards
o Management information format (MIF),
similar to MIB
o Program interface with two APIs
137
DMI Service Layer
DMI Functions
DMI MIB
• MIF specified using ASN.1 syntax

• Can be managed by an SNMP manager
• DMTF task expanded to specify WBEM -
Web-based enterprise management
138
• DMTF
Distributed Management Task Force
Web-Based Enterprise Management
139
Web-Based Enterprise Management
• WBEM based on Common Information Module,

developed by Microsoft
• CIM is information-modeling framework intended
to accommodate all protocols and frameworks
• Object-oriented
• Five components:
• Web client
• CIM object manager (CIMOM)
• CIM schema
• Management protocol
• Managed objects with specific protocol
Microsoft WMI
Microsoft WMI
• WMI is Microsoft infrastructure to support WBEM CIM

• WMI comprises management infrastructure,
applications, and agents
• CIMOM has plug-in management applications
• COM/DCOM API specifies interface to CIMOM
• CIM is the CIM schema
• Object providers are management agents (e.g. SNMP agent)
140
Service Driven Network
• Network of services (instead of network of components)

• based on Java technology and thin clients.
• It speeds up service creation and deployment, as well as handling provisioning,
management and billing.
• Dynamic Management
• The Service-Driven Network enables you to reconfigure the infrastructure of the
network dynamically, by pushing services in real-time, both to the network
infrastructure elements, and to consumer devices across the Internet.
• Java technology calls plug-in JavaBean
• MBean is management JavaBean
JDMK
- Java Dynamic Management Kits
JDMK
• Java dynamic management tool kit to build Java-based NMS

• MBean is an intelligent agent; does not need polling as in SNMP agent
• JDMK library of core management services
implemented as MBeans
• Java Dynamic Management agent comprises
• MBeans: core management framework,
MBean server
• Protocol adaptors: interfaces to applications
MBean Flow Diagram
141
142
143
JMX Architecture
Jiro Platform
144
145
Looking Ahead
• Future network and system management frameworks should accommodate well-

established SNMP entities
• Web agents are intelligent and future points to the use of Web technology
• Web-based management offers two options
• WBEM is comprehensive and centralized approach to enterprise management;
accommodates both scalar and object-oriented schemes
• JMX is decentralized and uses Java technology; agents embedded in objects and can be
downloaded from NMS; platform independent
• Future NMS environment could be a merger of the old and the new - at least in the near
future
146
147
148
149
150

Network Management Science

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Network Management Science

Hochgeladen von

Copyright:

Verfügbare Formate

Network Management Systems

1. Data Communications and Network Management Overview.

2. SNMPv1 Network Management: Organization and Information Models.

3. SNMPv1 Network Management: Communication and Functional Models.

4. SNMP Management: SNMPv2.

5. SNMP Management: RMON.

RMON1 Ethernet Management Information Base.

6. Telecommunications Network Management.

7. Network Management Tools and Systems.

UNIT I DATA COMMUNICATIONS AND NETWORK

• Analogy of telephone network

• Good operation and management of network

• Notice the hierarchy of switches

Operations Systems / NOC

• Monitor telephone network parameters.

Data and Telecommunication Network

 Computer data is carried over long distance by telephone

IBM SNA Architecture

 IBM System Network Architecture (SNA) is a major step in network architecture.

Distributed Computing Environment with LAN

• Driving technologies for DCE:

• Major impacts of DCE:

TCP/IP Based Networks

• TCP/IP is a suite of protocols

• Walk through the scenario of e-mail from Joe to Sally

• Examples: (Students to call out)

• Inter-layer interface: user and service provider

OSI Reference Model

• Importance of the knowledge of layer structure

OSI Layers and Services

• Importance of services offered by different layers

PDU Communication Model

• What is the relevance of PDU model in NM?

• cc:mail from a station in Novel IPX network to

SNA, OSI, and Internet

• Similarity between SNA and OSI

Internet user OSI user

Telnet Virtual Terminal

File Transfer Protocol File Transfer Access & Mgmt

Simple Mail Transfer Message-oriented Text

Simple Network Common Management

• The case of the Footprint

Common Network Problems

NM Functional Flow Chart

• Message exchange between NMSs managing

Status and Future Trends

SNMPV1 NETWORK MANAGEMENT-ORGANIZATION

• AT&T Network Management Centers

• NMS on subnet 192.168.252.1 manages the router and

Managed Hub: System Information

• Information obtained querying the hub

Managed Router: System Information

Managed Hub: Port Addresses

• Information acquired by the NMS on hub interfaces

Managed Router: Port Addresses

• Information acquired by NMS on the router interfaces

• Ethernet 2/0 interface refers to the interface

Internet SNMP Management

• 1970’s Advanced Research Project Agency Network (ARPANET)

SNMPv1 & SNMPv2 Documents

Two-Tier Organization Model

• Any host that could query an agent is a manager

Three-Tier Organization Model: RMON

• Managed object comprises network element and