0% found this document useful (0 votes)
23 views

Unit Ii

Network managemeent

Uploaded by

Durga Devi P
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views

Unit Ii

Network managemeent

Uploaded by

Durga Devi P
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 39

NETWORK MANAGEMENT

NETWORK MANAGEMENT
STANDARDS OSI/CMIP
• International standard (ISO/OSI)
• Management of data communications networks--LAN & WAN
• Deals with all 7 layers
• Object oriented
• Well structured & layered
• Consumes large resource in implementation
• The OSI management protocol standard is CMIP (Common Management Information Protocol) , & has
built-in services ,CMIS (Common Management Information Service) that specify the basic services
needed to perform the various functions
SNMP/Internet
• Industry standard (IETF)
• Originally intended for management of Internet components, currently adopted for WAN &
telecommunication systems
• Easy to implement
• Most widely implemented
TMN
• International standard (ITU-T)
• Management of telecommunications network
• Based on OSI network management framework
• Addresses both network & administrative aspects of management
IEEE
• IEEE standards adopted internationally
• Addresses management of LANs & MANs
• Adopts OSI standards significantly
• Deals with first 2 layers of the OSI reference model
Web Based Management
• This is based on using Web technology, a web server for the management system and web browsers for
network management stations
• Web Based Enterprise Management (WBEM)
• Java Management Extensions (JMX)
• DMTF (Desktop Management Task Force) is developing specifications for WBEM.
• JMX is based on a special subset of Java applets developed by Sun microsystems that runs in the
network components
NETWORK MANAGEMENT
NETWORK MANAGEMENT MODEL
• OSI network management architecture model comprises of 4 models: organization model, information model,
communication model & functional model (Figure: 3.1).
• The functional model deals with the user-oriented requirements of network management.
• The information model deals with the structure & organization of management information.
• The communication model has 3 components: management application processes that function in the application
layer, layer management between layers and layer operation within the layers.
• The organization model describes the components of a network management system, their functions and their
infrastructure.
NETWORK MANAGEMENT
ORGANIZATION MODEL
• The organization model describes the components of network management & their relationships.
Two Tier Network Management Organization Model
• In two tier model (Figure: 3.2), network objects consists of network elements such as hosts, hubs, bridges, routers
etc.
• They can be classified into managed & unmanaged objects or elements.
• The managed elements have a management process running in them called an agent.
• The manager manages the managed element.
• There is a database in the manager but not in the agent.
• The manager queries the agent & receives management data, processes it & stores it in its database.
Three Tier Network Management Organization Model
• In 3 tier model, the intermediate layer acts as both agent & manager (Figure: 3.3),
• As manager, it collects data from the network elements, processes it & stores the results in its database.
• As agent, it transmits information to the top-level manager.
Network Management Model with MoM
• Network domains can be managed locally and a global view of the networks can be monitored by a MoM
(Manager of managers).
• This configuration uses an enterprise network management system & is applicable to organizations with sites
distributed across cities (Figure: 3.4).
NETWORK MANAGEMENT
INFORMATION MODEL
• An information model is concerned with the structure & the storage of information (Figure: 3.6).
• Information on network components is passed between the agent & management processes.
• The information model specifies the information base to describe managed objects & their relationships.
• The SMI defines the syntax & semantics of management information stored in the MIB.
• The MIB is used by both agent & management processes to store & exchange management information.
• A manager MIB consists of information on all the network components that it manages whereas an agent MIB
needs to know only its local information, its MIB view.
• The MDB is a real database & contains the measured or administratively configured value of the elements of the
network. On the other hand, the MIB is a virtual database & contains the information necessary for processes to
exchange information.
NETWORK MANAGEMENT
COMMUNICATION MODEL
• Management data is communicated between agent & manager processes, as well as between manager processes.
• Three aspects need to be addressed in the communication of information between 2 entities: transport medium of
message exchange, message format of communication and the actual message.
Management Communication Model
• In the communication model (Figure: 3.11), the applications in the manager module initiate requests to the agent
in the Internet model.
• The agent executes the request on the network elements and returns responses to the manager.
• The notifications/traps are the unsolicited messages such as alarms, generated by the agent.
Management Communication Transfer Protocols
• Figure: 3.12 presents the communication protocol used to transfer information between managed object &
managing processes, as well as between management processes.
• The OSI model uses CMIP along with CMIS. Internet uses SNMP for communication.
• OSI uses both connection oriented and connectionless protocols for transportation. Internet uses connectionless
UDP/IP protocol to transport messages.
• CMIP & SNMP specifies the management communication protocols for OSI & Internet management
respectively.
NETWORK MANAGEMENT
MANAGEMENT INFORMATION TREES
• Managed objects are uniquely defined by a tree structure specified by the OSI model & are used in the Internet
model (Figure: 3.8).
• There is root node & well-defined node underneath each node at different levels.
• Each managed object occupies a node in the tree (e.g. Internet is designated as 1.3.6.1).
• In the OSI model, the managed objects are defined by a containment tree that represents the MIT.
• The root node does not have an explicit designation.
• The iso defines the International Standards Organization and itu defines the International Telecommunications
Union.
• The 2 standards organizations are on the first layer & define management of objects under them.
• The joint iso-itu node is for management objects jointly defined by the 2 organizations.
NETWORK MANAGEMENT
CONCEPTUAL VIEWS OF MANAGED OBJECTS (INTERNET & OSI PERSPECTIVE)
• A managed object in the Internet model is defined by 5 parameters (Figure: 3.9a):
→ object identifier & descriptor: unique ID & name for the object type
→ syntax: used to model the object
→ access: access privilege o a managed object
→ status: implementation requirements
→ definition: textual description of the semantics of object type
• The Internet object model is a scalar model & is easy to understand. In contrast, the OSI perspective of a
managed object is complex & has a different set of characteristics
• OSI specifications are object-oriented, and hence a managed object belongs to an object class
• The attribute of an object defines the external perspective of the object
• An OSI managed object has the following characteristics
→ object class: managed object
→ attributes: attributes visible at its boundary
→ operations: operations that can be applied to it
→ behaviour: behavior exhibited by it in response to an operation
→ notification: notifications emitted by the object
• Operation in the Internet model is done by get & set commands. Notification is done by response & alarm
messages.
• In OSI, we can create & delete objects. These concepts do not exist in the Internet.
NETWORK MANAGEMENT
ASN.1
• ASN.1 stands for Abstract Syntax Notation One.
• This is a formal language developed jointly by CCITT & ISO for use with application layers for data transfer
between systems.
• This is also applicable within the system for clearly separating the abstract syntax and the transfer syntax at the
presentation layer.
• Abstract syntax is defined as the set of rules used to specify data types and structures for storage of information.
• Transfer syntax represents the set of rules for communicating information between systems.
• Abstract syntax is applicable to the information model and transfer syntax to the communication model
• The algorithm to convert the textual ASN.1 syntax to machine readable code is called BER (Basic Encoding
Rules).

ASN.1 CONVENTIONS
• ASN.1 is based on the Backus system & uses the formal syntax language & grammar of the BNF (Backus-Nauer
Form) ,which looks like
<name>::=<definition>
where the notation <entity> denotes an "entity" and the symbol ::= represents "defined as"
e.g.: <BooleanType>::= BOOLEAN
<BooleanType>:= TRUE | FALSE
The definitions on the right side are called primitives
The format of each line is defined as a production or assignment
Entities that are all in capital letter such as TRUE and FALSE are called keywords
• A group of assignments makes up an
module. eg: person-name Person-
Name ::=
{
first "john"
middle "T"
last "smith"
}
Here "person-name" is the name of the module which is a data type. "Person-Name" is a module
• Following are 3 constructive mechanisms:
→ alternatives: CHOICE
→ list: SET and SEQUENCE
→ repetition: SET OF and SEQUENCE OF
• ASN.1 definition allows both backward & forward references as well as inline definition.
NETWORK MANAGEMENT
ASN.1 DATA TYPE
Simple Type
• A simple type one for which the values are specified directly. For example, we can define a page of a book as
PageNumber of simple type.
i.e. PageNumber::=INTEGER
ChapterNumber::=INTEGER
Structured Type
• A data type is a structured type when it contains other type.
• Types that are within a structured type are called component types. For example ,we can define all the pages of
the book as a collection of individual pages.
i.e. BookPages::=SEQUENCE OF
{
SEQUENCE {ChapterNumber , Separator ,PageNumber}
}
• SET is distinguished from SEQUENCE in 2 respects:
1) The data types should all be distinct and
2) The order of values in SET is of no consequence whereas it is critical in the SEQUENCE construct.
Tagged Type
• Tagged type is a type derived from another type that is given a new tag id.
• A tagged type is defined to distinguish types within an application.
Other Type
• Other type is a data type that is not predefined.
• This is chosen from CHOICE and ANY types, which are contained in other types.
• Type CHOICE defines the selection of one value from a specified list of distinct types.
NETWORK MANAGEMENT
ENCODING STRUCTURE
• The ASN.1 syntax that contains the management information is encoded using the BER defined for the transfer
syntax.
• The ASCII text data is converted to bit-oriented data.
• Example of encoding structure is TLV which denotes type, length & value components of structure (Fig: 3.18).
• The type has 3 subcomponents: class, P/C & tag number (Table: 3.6).
• P/C specifies whether the structure is a primitive, or simple, type or a construct.
• This is encoded as a one byte (an octet) field.
• The value of P/C is 0 for primitive & 1 for construct.

FUNCTIONAL MODEL
• The functional model component addresses the user-oriented applications, which are formally specified in the
OSI model (Figure: 3.22).
• The functional model consists of 5 submodels: configuration management, fault management, performance
management, security management and accounting management.
(same as in chapter 1).
NETWORK MANAGEMENT

UNIT 3: SNMPv1 NETWORK MANAGEMENT—


ORGANIZATION & INFORMATION MODELS

MANAGED LAN NETWORK


• An NMS can automatically discover any component in the network as long as the component has a management
agent. For eg, the management agent may be TCP/IP suite that responds to a ping by the NMS (fig:4.1).
• Ethernet LAN consists of a router & 2 hubs and is connected to the backbone network .
• The IP address 172.16.46.1 is the address assigned to the interface card in the router.
• The interface cards in the router and the interface card in each of the hubs are connected by a cat-5 cable, forming
the Ethernet LAN.
• The NMS (whose IP address is 192.168.252.1) is physically & logically located remotely from the 172.16.46.1
LAN.
• Information system managers establish conventions to designate a network and a subnetwork. A 0 in the 4th
decimal position of an IP address designates a network and 1 in the 4th decimal position designates a subnetwork.
• Once the network components have been discovered & mapped by the NMS ,we can query & acquire information
on system parameters and statistics onthe network elements.

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
NETWORK MANAGEMENT
SNMP ORGANIZATION MODEL
Two-Tier Model
• This consists of an agent process, which resides in the managed object, and a manager process, which resides in
the NMS and manages the managed object. (Fig:4.5).
• Both the manager and the agent are software modules.
• The agent responds to any NMS that communicates with it using SNMP. Thus, multiple managers can interact
with one agent.
• In the 2-tier models, the network manager receives raw data from agents & processes them. Sometimes, it is
beneficial for the network manager to obtain preprocessed data. Instead of the network manager continuously
monitoring the events and calculating the information, an intermediate agent called RMON is inserted between the
managed object and the network manager.

Three-Tier Model
• In 3-tier organization model, the network manager receives data from the managed objects as well as data from
the RMON agent about the managed objects (Fig: 4.6).
• The RMON function has greatly increased the centralized management of networks.

Three-Tier Model with Proxy Server


• Normally, the pure SNMP management system consists of SNMP agents and SNMP managers. However, an
SNMP manager can manage a network element that does not have an SNMP agent. This is shown in fig: 4.7
• This model is applicable in many situations, such as legacy systems management, telecommunications network
management, wireless networks management and so on.
• A proxy server converts the data into a set that is compatible with SNMP and communicates with the SNMP
manager.
NETWORK MANAGEMENT
SNMP NETWORK MANAGEMENT ARCHITECTURE
• This portrays the data path between the manager application process and the agent application process via the 4
transport protocols: UDP, IP, DLC & PHY. The 3 application layers above the transport layer are integrated in the
SNMP process (fig: 4.9).

• The communication of management information among management entities is realized through exchange of
following 5 protocol messages:
1) The get-request message is generated by the management process requesting the value of an object.
2) The get-next-request is similar to get-request. In many situations, an object may have multiple values
because of multiple instances of the object.
3) The set-request is generated by the management process to initialize or reset the value of an object
variable.
4) The get-response message is generated by an agent process. It is generated only on receipt of a get-
request, get-next-request or set-request message from a management process.
5) A trap is an unsolicited message generated by an agent process without a message or event arriving
from the manager process.

• The SNMP manager has a database that polls the managed objects for management data. It contains 2 sets of
data: one on the information about the objects, MIB and a second on the values of the objects, MDB
1) A MIB is a virtual database and is static. In fact, a MIB needs to be there when an NMS discovers a new
object in the network. It is compiled in the manager during the implementation.
2) A MDB is dynamic and contains the measured values associated with the object. This is a true database.
It is implemented using any database architecture chosen by the implementers.
NETWORK MANAGEMENT

UNIT 4: SNMPv1 NETWORK MANAGEMENT —


ORGANIZATION & INFORMATION MODELS (CONT.)

SMI
• SMI stand for Structure of Management Information.
• A managed object can be considered to be composed of an object type and an object instance (fig:4.10).
• SMI is concerned only with the object type and not object instance. i.e. the object instance is not defined by SMI
• Object type, which is a data type, has following:
1) The name is represented uniquely by a descriptor and object identifier. For example,

2) The syntax of an object type is defined using the ASN.1.


3) BER have been adopted as the encoding scheme for transfer of data types between agent and manager
processes as well as between manager processes.

• Every object type (i.e. every name) is uniquely identified by a DESCRIPTOR and an associated OBJECT
IDENTIFIER. (fig:4.11).
• Internet MIB has its OBJECT IDENTIFIER 1.3.6.1, which can be defined as
internet OBJECT IDENTIFIER::{iso org(3) dod(6) 1}
• Any object in the Internet MIB will start with the prefix 1.3.6.1 or internet. For eg, there are 4 objects under the
internet object (fig:4.13)
1) The directory(1) node i reserved for future use of OSI Directory in the Internet.
2) The mgmt(2) is used to identify all IETF-recommended and IAB-approved sub-nodes and objects.
3) The experimental(3) node was created to define objects under IETF experiments.
4) The private(4) node is a heavily used node. Commercial vendors can acquire a number under
enterprises(1),which is under the private(4) node.
NETWORK MANAGEMENT
SNMP-BASED ASN.1 DATA TYPE STRUCTURE

• Defined are defined using primitive types. The primitive types used are NetworkAddress, IpAddress, Counter,
Gauge and TimeTicks.
• NetworkAddress is a choice of the address of the protocol family. For eg, TCP/IP-based Internet family, which
uses the base type IpAddress.
• IpAddress is the conventional four groups of dotted decimal notation of IPv4, for e.g. 190.146.252.255. The 32
bit string is designated as OCTET STRING of length 4,in network byte order.
• Counter is an application-wide data type and is a non-negative integer. It can only increase in value up to a
maximum of 232-1 and then wraps around starting from 0. Counter types is useful for defining values of data types
that continually increase such as input packets received on an interface or output packet errors on an interface.
• Gauge is also a non-negative integer, but its value an move either up or down. It pegs at its maximum value of
232-1. Gauge is used for data types whose value increases or decreases such as the number of interfaces that are
active in a router or hub.
• TimeTicks is a non-negative integer and measures time in units of hundredths of a second. Its value indicates in
hundredths of a second the number of units of time between the current instant and the time it was initialized to 0.
The maximum value is 232-1.
• Opaque is used to specify octets of binary information. It is an application-wide data type that supports the
capability to pass arbitrary ASN.1 syntax. It is used to create data types based on previously defined data types. Its
size is undefined in SNMPv1, which causes some problem in its implementation.
NETWORK MANAGEMENT
MANAGED OBJECTS
• A managed object has following 5 parameters:
1) The textual name for an object type is mnemonic and is defined as OBJECT DESCRIPTOR. OBJECT
DESCRIPTOR defines only the object type and not the occurrence or instantiation of it. Associated with
each OBJECT DESCRIPTOR is an OBJECT IDENTIFIER, which is the unique position it occupies in the
MIB,
2) Syntax is the ASN.1 definition of the object type,
3) A definition is an accepted textual description of the object type. It is a basis for the common language,
or semantics, to be used by all vendors. It is intended to avoid confusion in the exchange of information
between the managed object and the management system as well as between the various network
management systems,
4) Access is the specification for the type of privilege associated with accessing the information: read-only,
read-write or not-accessible. Its value is defined by the system vendor during the manufacturing process,
5) Status specifies whether the managed object is current or obsolete. The 3 choices for status are
mandatory, optional and obsolete. A managed object, once defined, can only be made obsolete and not
removed or deleted. If it is current, the implementation of it is specified as either mandatory or optional,

MACROS FOR MANAGED OBJECTS

• The body of the macro module consists of 3 parts: type notation, value notation and supporting productions.
1) TYPE NOTATION defines the object types in the module and VALUE NOTATION defines the name of
the object,
2) Access can be only one of 4 options: read-only, read-write, write-only or not-accessible,
3) Allowed values for Status are mandatory, optional or obsolete,
NETWORK MANAGEMENT
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
• 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 MANAGED OBJECT MACRO


• Index ipAdEntAddr uniquely identifies an instance.
• May require more than one object in the instance to uniquely identify it.
Table Object

Entry Object
NETWORK MANAGEMENT
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 objects1 through 5.
• Multiple instances of E are represented by multiple rows.
• Notice that the column-row numeric designation is reverse of what we are used to as row-column.
NETWORK MANAGEMENT
MIB
• MIB stand for Management Information Base.
• This is a virtual information base. Managed objects are accessed via this virtual information base.
• Objects in the MIB are defined using ASN.1. The objects defined in MIB-2 have the OBJECT IDENTIFIER
prefix:
mib-2 OBJECT IDENTIFIER ::= {mgmt 1}

OBJECT GROUPS
• Objects that are related are grouped into object groups.
• Object groups facilitate logical assignment of object identifiers.
• One of the criteria for choosing objects to be included in standards is that the object is essential for either fault or
configuration management.

• 11 groups are defined in MIB2. (Fig:4.26).


NETWORK MANAGEMENT
SYSTEM GROUP
• The System group is the basic group in the Internet standard MIB (fig:4.27).
• Its elements are probably the most accessed managed objects.
• After an NMS discovers all the components in a network or the new components in the network,it has to obtain
information on the system it discovered such as system name,object ID and so on.
• The NMS will initiate the get-request message on the objects in this group for this purpose.
• The group also has administrative information such as contact peron and physical location, that helps a network
manager.
• Implementation of the System group is mandatory for all systems in both agent & manager.
NETWORK MANAGEMENT
INTERFACES GROUP
• The Interface group contains managed objects associated with the interfaces of a system.
• If there is more than one interface in the system, the group describes the parameters associated with each interface
• This specifies the number of interfaces in a network component and the managed objects associated with each
interface.
• Implementation of the Interfaces group is mandatory for all system.
NETWORK MANAGEMENT
NETWORK MANAGEMENT
TCP GROUP

TCP CONNECTION TABLE

UDP GROUP
NETWORK MANAGEMENT

UNIT 4(CONT.): SNMPv1 NETWORK MANAGEMENT —


COMMUNICATION & FUNCTIONAL MODELS

SNMP COMMUNICATION ARCHITECTURE


• The SNMP architecture consists of communication between network management stations and managed network
elements. (Fig:4.9).
• Network elements have built-in management agents if they are managed elements.
• The SNMP communication protocol is used to communicate information between the network management
stations and the management agents in the elements.
• Only non-aggregate objects are communicated using SNMP. The aggregate objects are communicated as
instances of the object.
• ASN.1 and BER are used for data transfer in SNMP.
• The information about the network is obtained primarily by the management stations polling the agents.
• The SNMP manages the network with the following 5 messages:
1) The get-request message is generated by the management process requesting the value of an object.
2) The get-next-request is similar to get-request. In many situations, an object may have multiple values
because of multiple instances of the object.
3) The set-request is generated by the management process to initialize or reset the value of an object
variable.
4) The get-response message is generated by an agent process. It is generated only on receipt of a get-
request, get-next-request or set-request message from a management process.
5) A trap is an unsolicited message generated by an agent process without a message or event arriving
from the manager process.
• Following are 3 types of traps:
1) The generic trap type consists of coldStart, warmStart, linkDown, linkUp, authenticationFailure,
egpNeighbourLoss and enterpriseSpecific.
2) The specific-trap is a specific code and is generated even when an enterpriseSpecific trap is not present.
3) The time-stamp is the time elapsed between the last initialization or re-initialization of the element and
the generation of the trap.
NETWORK MANAGEMENT
ADMINISTRATIVE MODEL
• The application entity that reside in the management station is called SNMP manager, and the application entity
that reside in the network element is called SNMP agent.. The pairing of these two entities is called an SNMP
community.
• In (fig:5.1),while an SNMP manager is monitoring traffic on an element, another manager can be configuring
some administrative information on it. A third manager can be monitoring it to perform some statistical study.
• In (fig:5.1),the authentication scheme is filter module in the manager and in the agent. The simplest form of
authentication is the common community name between the two application entities.
• A network element comprises many managed objects, both standard & private. However,a management agent
may be permitted to view only a subset of the network element's managed objects. This is called the community
MIB view (fig:5.2).
• In addition to the MIB view, each community name is also assigned an SNMP access mode either READ-ONLY
or READ-WRITE.
• The pairing of the SNMP MIB view with the SNMP access mode is called the community profile.
• A community profile in combination with the access mode of a managed object determines the operation that can
be performed on the object by an agent.
NETWORK MANAGEMENT
SNMP ACCESS POLICY
• A pairing of an SNMP community with an SNMP community profile is defined as SNMP access policy. This
defines the administrative model of SNMP management.
• In fig:5.3, agent 1 and 2 belong to Community 1. However, they have different community profiles, community
profiles 1 and 2.
• Manager 1, which is part of Community 1, can communicate with both Agents 1 and 2. However, it cannot
communicate with Agents 3 and 4, which belong to Community 2. Manager 2 has access to them because it also
belongs to Community 2.
• The SNMP access policy can be extended to managing a non-SNMP community that uses the SNMP proxy
access policy (fig:5.4).
• The SNMP agent associated with the proxy policy is called a proxy agent or commercially a proxy server.
• The proxy agent monitors a non-SNMP community with non-SNMP agent and then converts the objects and data
to SNMP-compatible objects and data to feed to an SNMP manager.
NETWORK MANAGEMENT
SNMP PROTOCOL SPECIFICATIONS
• The peer processes, which implement the SNMP, and thus support the SNMP application entities, are called
protocol entities.
• Communication among protocol entities is accomplished using messages encapsulated in UDP datagrams.
• An SNMP message consists of a version identifier, an SNMP community name and a PDU (fig:5.5).
• An SNMP protocol entity is received on port 161 on the host except for trap, which is received on port 16a
• The maximum length of the protocol in SNMPv1 is 484 bytes.
• This is mandatory that all five PDUs be supported in all implementations:GetRequest-PDU,GetNextRequest-
PDU,GetResponse-PDU,SetRequest-PDU and Trap-PDU.
• Basic operations of the protocol entity involve the following steps as a guide to implementation:
1) The protocol entity that generates the message constructs the appropriate data PDU as an ASN.1 object.
2) It then passes the ASN.1 object, along with a community name and the transport addresses of itself and
the destination ,to the authentication scheme.
3) The authentication scheme returns another ASN.1 object.
4) The protocol entity now constructs the message to be transmitted with the version number, community
name and the new ASN.1 object, then serializes it using the BER, and transmits it.
5) The reverse process goes on at the receiver.
6) The message is discarded if error is encountered in any of the steps.
7) A trap may be generated in case of authentication failure.
8) On successful receipt of the message, a return message is generated, if the original message is a get or
set message.
NETWORK MANAGEMENT
GET AND SET TYPE PDUS
• In fig:5.8, RequestID is used to track a message with the expected response or indicate loss of the message. Loss-
of-message detection is implementation specific, such as time out if no response is received for a request within a
given time.
• ErrorStatus is used to indicate that an error occurred.
• ErrorIndex is used to provide additional information on the error status. The value is filled with NULL in cases
where it is not applicable. Otherwise, it is filled with the varBind number where the error occurred.

TRAP PDU
• In fig:5.9, the enterprise and agent-address pertain to the system generating the trap.
• The generic-trap consists of following 7 types:
→ coldStart(0):sending protocol entity is reinitializing itself, agent's configuration or protocol entity
implementation may be altered.
→ warmStart(1):sending protocol entity is reinitializing itself, agent's configuration or protocol entity
implementation not altered.
→ linkDown(2):failure of one of the communication links.
→ linkup(3):one of the links has come up.
→ authenticationFailure(4):authentication failure.
→ egpNeighborLoss(5):loss of EGP neighbor.
→ enterpriseSpecific(6):Enterprise-specific trap.
• The integer in parenthesis associated with each name indicates the enumerated INTEGER.
• The specific-trap is a trap that is not covered by the enterpriseSpecific trap.
• Time-stamp indicates the elapsed time since last re-initialization.
NETWORK MANAGEMENT
GETREQUEST-PDU OPERATION

GETNEXTREQUEST-PDU OPERATION
NETWORK MANAGEMENT
LEXICOGRAPHIC ORDER

• Procedure for ordering:


1) Start with leftmost digit as first position.
2) Before increasing the order in the first position, select the lowest digit in the second position.
3) Continue the process till the lowest digit in the last position is captured.
4) Increase the order in the last position until all the digits in the last position are captured.
5) Move back to the last but one position and repeat the process.
6) Continue advancing to the first position until all the numbers are ordered.
• Tree structure for the above process is shown below:
NETWORK MANAGEMENT
USE OF GETNEXTREQUEST-PDU OPERATION
• In fig:5.12, the first two objects, A and B, are single-valued scalar objects.
• They are followed by an aggregate object represented by the table T with an entry E and two rows of three
columnar objects, T.E.1.1 through T.E.3.2.
• The MIB group ends with a scalar object Z.
• fig:5.13 shows the use of nine get-request messages to retrieve the nine objects.
NETWORK MANAGEMENT
FUNCTIONAL MODEL
NETWORK MANAGEMENT

UNIT 5: SNMP MANAGEMENT – RMON

WHAT IS REMOTE MONITORING?


• The monitored information, gathered & analyzed locally, can be transmitted to a remote network management
station. In such a case, remotely monitoring the network with a probe is referred to as RMON (Remote Network
Monitoring) (fig:8.1).
• Two remote LANs, one a token ring LAN and another, an FDDI LAN ,are connected to the backbone network.
The NMS is on the local Ethernet LAN.
• An Ethernet probe 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 token ring probe monitors the token ring LAN. It communicates
with the NMS via the routers ,the WAN & the backbone network The remote FDDI is monitored by the built-in
probe on the router. The FDDI probe communicates with NMS.
• All 4 probes that monitor the 4 LANs and communicate with the NMS are RMON devices.
Advantages:
1) Each RMON device monitors the local network segment and does the necessary
analyses. This relays information in both solicited & unsolicited fashion to the
NMS.
For example, RMON could be locally polling the network elements in a segment. If it
detects an abnormal condition such as heavy packet loss or excessive collisions, it sends
an alarm. Because the polling in local, the information is fairly reliable.
The local monitoring and reporting to a remote NMS significantly reduces
SNMP traffic in the network.
2) RMON reduces the need for agents in the network to be visible at all times to the NMS.
3) Monitoring packets such as ICMP pings, may get lost in long-distance communication, especially under
heavy traffic conditions. Such losses may wrongly be interpreted by the NMS that the managed object is
down. RMON pings locally and hence has less chance of losing packets, thus increasing monitoring
reliability.
4) The individual segments can be monitored almost continuously. This capability provides better statistics
and control.
Thus a fault can be diagnosed more quickly by the RMON and reported to the NMS.
5) RMON provides higher network availability for users and greater productivity for administrators.
NETWORK MANAGEMENT
RMON1 GROUPS & FUNCTIONS
• The data gathering modules, which are LAN probes, gather data from the remotely monitored network.
comprising Ethernet & token ring LANs. The data can serve as inputs to 4 sets of functions, 3 of which monitor
traffic statistics(fig:8.3).
• The functions performed by various groups is as follows:
1) Statistics: provides link level statistics.
2) History: collects periodic statistical data & stores them for later retrieval.
3) Alarm: generates events when the data sample gathered crosses pre-established threshold.
4) Host: gathers statistical data on hosts.
5) Host Top N: computes the top N hosts on the respective categories of statistics gathered.
6) Matrix: gathers statistics on traffic between pairs of hosts.
7) Filter: performs filter function that enables capture of desired parameters.
8) Packet capture: provides packet capture capability for gathering packets after they flow through a
channel.
9) Event: controls the generation of events & notifications.
• The outputs of the various modules are analyzed & presented in tabular and graphical forms to the user by the
network manager in the NMS.
• The filter group is a cascade of 2 filters. The packet filter filters incoming packets by performing a Boolean
and/or XOR with a mask specified. The filtered packet stream is considered a channel, and we can make further
selections based on the channel mask.
• The filtered outputs may generate either alarms or events, which are reported to the network manager. The output
of the filter group can be stored in the packet capture module for further analysis by the network manager.
NETWORK MANAGEMENT
NETWORK MANAGEMENT
THE RMON MANAGEMENT INFORMATION BASE
• The RMON2 MIB is arranged in 10 groups:
1) The protocol directory group identifies the protocols that the probe can monitor.
2) The protocol distribution group provides information on the relative traffic of different protocols either
in octet or packets. It collects basic statistics that help a NMS manage bandwidth allocation utilized by
different protocols.
3) The address map group binds the MAC address to network address on each interface.
4) The network layer host group measures the traffic sent from and to each network address representing
each host discovered by the probe.
5) The network layer matrix group provides information on the conversation between pairs of hosts in both
directions.
6) Both application layer host and application layer matrix groups calculate traffic by protocol units and
use their respective control tables in the network layer host group and the network layer matrix group.
7) Alarm and history information are combined into the user history collection group. This function,
normally done by NMS, can be off-loaded to RMON.
8) The probe configuration group provides the facility for configuring the probe.The data can be accessed
via a modem connection.

RMON TOKEN RING MIB GROUPS & TABLES

1) The MAC layer statistics group collects data on token ring parameters such token packets ,errors in packets
,bursts ,polling etc.
2) The promiscuous statistics group collects statistics on the number of packets of various sizes and the type of
packets-- multicast or broadcast data.
3) The ring station group provides statistics on each station being monitored on the ring ,along with its status. The
data are stored in the ringStationTable. The rings and parameters to be monitored are controlled by the
ringStationControlTable.
4) The ring station order group provides the order of the station on the monitored rings & has only a data table
5) The ring station configuration group manages the stations on the ring.
6) The Source routing group gather statistics on routing information in a pure source routing environment.
NETWORK MANAGEMENT
RMON2 MIB GROUPS AND TABLES
• Applicable to Layers 3 and above.
• Functions similar to RMON1.
• Enhancement to RMON1.
• Defined conformance and compliance.
NETWORK MANAGEMENT
ATM REMOTE MONITORING
• Switch extensions for RMON & ATM RMON define RMON objects at the base layer, which is the ATM
.sublayer. ATM protocol IDs for RMON2 define additional objects needed at the higher levels. (Fig:8.7) .
• Extending RMON to ATM devices requires design changes and new functionality.
• Particular attention must be paid to high-speed requirements, cells versus frames, and the connection-oriented
nature of ATM.
• The high-speed nature of ATM imposes a severe set of requirements in ATM RMON implementation.
• At the data link sublayer, ATM RMON measures cells instead of packets or frames, and provides cell-based per-
host and per-conversation traffic statistics At the application layer, RMON provides basic statistics for each
monitored cell stream, for each ATM host, and for conversations between pair-wise hosts .
• It also provides the capability for flexible configuration mechanisms suited to the connection-oriented nature of
ATM.
• When RMON instrumentation is embedded in the switch fabric (part c & d) ,no modification of the circuit is
needed. In part a & b , circuit steering is needed to copy the cells onto the probe(Fig:8.8) .
NETWORK MANAGEMENT
ATM RMON MIB GROUPS AND TABLES
• ATM RMON MIB contains four groups.
• portSelect group selects ports.
• atmStats collects basic statistics based on portselection.
• atmHost gathers statistics based on host traffic.
• atmMatrix group collects conversation traffic and ranks the top-N entries.

You might also like