0% found this document useful (0 votes)
98 viewsNMS
Network Management System
Uploaded by
bonfireeCopyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
98 viewsNMS
Network Management System
Uploaded by
bonfireeCopyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
/ 35
cHarrens SNMP Management
Information
‘As with any network management system, the foundation of a TCP/P-based network
management system is a database containing information about the elements to be man-
aged. In both the TCP/IP and the OSI environments, the database is referred to as a man-
agement information base (MIB), Each resource to be managed is represented by an
object. The MIB is a structured collection of such objects. For SNMP, the MIB is, in
essence, a database structure in the form of a tree. Each system (workstation, serve,
router, bridge, etc.) in a network or internetwork maintains a MIB that reflects the status of
the managed resources at that system. A network management entity can monitor the re-
sources at that system by reading the values of objects in the MIB and may control the
resources at that system by modifying those values.
In order for the MIB to serve the needs of a network management system, it must
meet certain objectives.
1. The object or objects used to represent a particular resource must be the same at each
system. For example, consider information stored concerning the TCP entity at a sys-
tem, The total number of connections opened over a period of time consists of active
opens and passive opens, The MIB at the system could store any two of the three rel-
evant values (number of active opens, number of passive opens, total number of
opens), from which the third could be derived when needed. However, if different
systems select different pairs for storage, it is difficult to write a simple protocol to
access the required information. As it happens, the MIB definition for TCP/IP speci-
fies that the active and passive open counts be stored,
2. A common scheme for representation must be used to support interoperability.
The second point is addressed by defining a structure of management information
(SMI), which we examine in this chapter, together with a look at some of the practical
issues involved in managing by means of managed objects. The first point is addressed by
defining the objects and the structuring of those objects in the MIB; Chapter 6 looks at
some important examples.
101 102
SNMP MANAGEMENT INFORMATION
5.1
SAL
This chapter makes use of the ASN.1 notation. The reader not familiar with this
notation should first consult Appendix B.
Structure of Management Information
The structure of management information (SMI), which is specified in RFC 1155, de-
fines the general framework within which a MIB can be defined and constructed.’ The
SMI identifies the data types that can be used in the MIB and specifies how resources
within the MIB are represented and named. The philosophy behind SMI is to encourage
simplicity and extensibility within the MIB. Thus, the MIB can store only simple data
types: scalars and two-dimensional arrays of scalars. We will see that SNMP can retrieve
only scalars, including individual entries in a table. The SMI does not support the cre-
ation or retrieval of complex data structures. This philosophy is in contrast to that used
with OSI management, which provides for complex data structures and retrieval modes
to support greater functionality.
SMI avoids complex data types to simplify the task of implementation and to en-
hance interoperability. MIBs will inevitably contain vendor-created data types, and
unless tight restrictions are placed on the definition of such data types, interoperability
will suffer.
To provide a standardized way of representing management information, the SMI
must do the following.
Provide a standardized technique for defining the structure of a particular MIB.
Provide a standardized technique for defining individual objects, including the syntax
and the value of each object.
Provide a standardized technique for encoding object values.
Let us consider each of these aspects in turn.
MIB Structure
All managed objects in the SNMP environment are arranged in a hierarchical or tree
structure. The leaf objects of the tree are the actual managed objects, each of which repre-
sents some resource, activity, or related information that is to be managed. The tree struc-
ture itself defines a grouping of objects into logically related sets.
Associated with each type of object in a MIB is an identifier of the ASN.1 type
OBJECT IDENTIFIER. The identifier serves to name the object. In addition, because the
1As part of the standardization effort for SNMPv2, a more elaborate SMI has been defined (SMIv2). In time, all
of the existing MIB specifications are to be rewritten using SMIv2. However, for preexisting MIBs, the changes
are minor. For the purposes of Part I, we will confine ourselves to a discussion of SMIv1. Structure of Management Information 103
value associated with the type OBJECT IDENTIFIER is hierarchical, the naming conven-
tion also serves to identify the structure of object types.
To summarize from Appendix B, the object identifier is a unique identifier for a par-
ticular object type. Its value consists of a sequence of integers. The set of defined objects
hhas a tree structure, with the root of the tree being the object referring to the ASN.1 stan-
dard, Beginning with the root of the object identifier tree, each object identifier compo-
nent value identifies an arc in the tree. Starting from the root, there are three nodes at the
first level: iso, ccitt, and joint-iso-ccitt. Under the iso node, one subtree is for
the use of other organizations, one of which is the U.S. Department of Defense (dod).
RFC 1155 makes the assumption that one subtree under dod will be allocated for admin-
istration by the Internet Activities Board as follows:
internet OBJECT IDENTIFIER
iso (1) org(3) dod(6) 1)
This is illustrated in Figure 5.1, Thus, the internet node has the object identifier
value of 1.3.6.1. This value serves as the prefix for the nodes at the next lower level of the
tree.
As shown, the SMI document defines four nodes under the internet node:
directory: reserved for future use with the OSI directory (X.500)
mgmt : used for objects defined in IAB-approved documents
experimental : used to identify objects used in Internet experiments
private: used to identify objects defined unilaterally
The mgmt subtree contains the definitions of management information bases that
have been approved by the IAB. At present, two versions of the MIB have been devel-
oped, mib-1 and mib-2. The sccond MIB is an extension of the first. Both are provided
with the same object identifier in the subtree since only one of the MIBs would be pres-
ent in any configuration.
Additional objects can be defined for a MIB in one of three ways:
1, The mib-2 subtree can be expanded or replaced by a completely new revision (pre-
sumably mib-3). To expand mib-2, a new subtree is defined. For example, the
remote network monitoring MIB, described in Part Ill, is defined as the sixteenth
subtree ander mib-2 (mib-2 (16)).
2. An experimental MIB can be constructed for a particular application. Such objects
may subsequently be moved to the mgnt subtree. Examples of these include the var-
ious transmission media MIBs that have been defined, such as the one for IEEE
802.5 token ring LAN (RFC 1231).
3. Private extensions can be added to the private subtree. One that is documented as
an RFC is the MUX MIB (RFC 1227). 104
iso (1)
org (3)
dod (6)
internet (1)
directory (1)
gmt (2)
mib-2 (1)
system (1)
interfaces (2)
at (a)
dp (4)
icmp (5)
tep (6)
udp (7)
eap (8)
transmission (10)
enmp (11)
experimental (3)
private (4)
enterprises (1)
FIGURE 5.1 MIB-II object groups Structure of Management Information 105
5.12
SAQA
The private subtree currently has only one child node defined, the enterprises
node, This portion of the subtree is used to allow vendors to enhance the management of
their devices and to share this information with other users and vendors who might need
to interoperate with their systems. A branch within the enterprise subtree is allocated
to cach vendor that registers for an enterprise object identifier.
The division of the internet node into four subtrees provides a strong foundation
for the evolution of MIBs. As vendors and other implementors experiment with new
objects, they are in effect gaining a good deal of practical know-how before these objects
are accepted as part of the standardized (mgmt) specification. Thus, the MIB is useful
immediately for managing objects that fit within the standardized portion of the MIB
and is flexible enough to adapt to changes in technology and product offerings. This evo-
lutionary character mirrors that of the protocols within the TCP/IP suite: All of these
protocols underwent extensive experimental use and debugging before being finalized as
standard protocols.
Object Syntax
Every object within an SNMP MIB is defined in a formal way; the definition specifies the
data type of the object, its allowable forms and value ranges, and its relationship to other
objects within the MIB. The ASN.1 notation is used to define each individual object and
also to define the entire MIB structure, In keeping with the objective of simplicity, only a
restricted subset of the elements and features of ASN.1 are used.
Universal Types
‘The UNIVERSAL class of ASN.1 consists of application-independent data types that are
of general use. Within the UNIVERSAL class, only the following data types are permitted
to be used to define MIB objects:
integer (UNIVERSAL 2)
octetstring (UNIVERSAL 4)
null (UNIVERSAL 5)
object identifier (UNIVERSAL 6)
* sequence, sequence-of (UNIVERSAL 16)
The first four are primitive types that are the basic building blocks of other types of
objects. Note that the enumerated type is not included. Therefore, when an enumerated
list of integers is to be defined, it must be done with the integer type. Two conventions
are associated with the use of enumerations,
© The value 0 may not be used. This allows for common encoding errors to be caught. 106
5.1.2.2
SNMP MANAGEMENT INFORMATION
* Only the enumerated integer values may be used. There is typically one enumerated
value labeled other, or something similar, to handle cases that don’t fit the other enu-
merated labels.
‘The object identifier is a unique identifier of an object, consisting of a sequence of
imegers, known as subidentifiers, The sequence, read from left to right, defines the loca-
tion of the object in the MIB tree structure. For example, looking ahead to Figure 6.10,
the object identifier for the object tepConnTabie is derived as follows:
iso org dod internet mgmt mib-2 tep tepConnTable
1 a 6 1 2 L 6 13
‘This identifier would normally be written as 1.3.6.1.2.1.6.13.
‘The last item in the preceding list consists of the constructor types sequence and
sequence-of. These types are used to construct tables, as explained later in this chapter.
Application-Wide Types
‘The APPLICATION class of ASN.1 consists of data types that are relevant to a particular
application. Each application, including SNMP, is responsible for defining its own
APPLICATION data types. RFC 1155 lists a number of application-wide data types; other
types may be defined in future RFCs. The following types are defined:
* networkaddress: This type is defined using the CHOICE construct, to allow the
selection of an address format from one of a number of protocol families. Currently,
the only defined address is IpAddress.
ipaddress: This is a 32-bit address using the format specified in IP.
counter : This is a non-negative integer that may be incremented but not decremented.
A maximum value of 2” - 1 (4,294,967,295) is specified; when the counter reaches its
maximum, it wraps around and starts increasing again from zero (Figure 5.2(a)).
gauge: This is a non-negative integer that may increase of, decrease, with a maxi-
mum value of 2-1. If the maximum value is reached, the gauge remains latched at
that value until reset (Figure 5.2(b)).
timeticks: This non-negative integer counts the time in hundredths of a second
since some epoch. When an object type is defined in the MIB that uses this type, the
definition of the object rype identifies the reference epoch
opaque: This type supports the capability to pass arbitrary data. The data is en-
coded as OCTET STRING for transmission. The data itself may be in any format
defined by ASN.1 or another syntax.
The counter, also known as the rollover counter, is one of the most common types
used in defining objects. Typical applications are to count the number of packets or octets Siruciure of Management Information 107
X= current
counter value
X= current
gauge value
2
counter may gauge does not
wrap at 0 wrap but may
(med 22) increase and
(@) Counter seoease (b) Gauge
FIGURE 5.2 Counter and gauge
sent or received, An alternative type of counter that the SMI designers considered is the
latch counter, which sticks at its maximum value and must be reset. The latch counter was
rejected because of the following potential problem. Suppose that more than one manage-
ment system is allowed access to a particular counter; that is, more than one management
system can monitor a device. When a latch counter reaches its maximum and needs to be
reset, there are two alternatives:
1. Designate one management system as responsible for latch reset. The problem with
this approach is that if that system fails, the counter remains stuck at its latched velue.
2. Allow any management system the authority to reset the counter when it deems it
appropriate. The problem here has to do with the time lag involved in communica-
tion across a distributed system. Several systems may reset the same counter, with
the result that some information is lost (counts that take place between the arrival of
the two resets at the managed object).
With rollover counters, these difficulties are avoided. However, after a rollover
counter has wrapped around several times, it is difficult for a management system to
know whether a counter value of x means that the quantity observed is x or (N x 2*) + x.
The only way around this is for the management station periodically to poll the object to
keep track of wraparounds. Because 32-bit counters are used, this should not have to be
done very often.
‘Typically, a gauge is used to measure the current value of some entity, such as the cur-
rent number of packets stored in a queue. A gauge can also be used to store the difference
in the value of some entity from the start to the end of a time interval. This enables a gauge
to be used to monitor the rate of change of the value of an entity. 2
$123
[SNMP MANAGEMENT INFORMATION
‘The amps type is eferred to asa latched value. There iss unfortanately, some
‘uty comcerning the meaning of the word “latch.” Its certainly the case that,
gauge reaches is marcimum value, it will noc roll ave to 2eo, Rather, ifthe gauge r
Sens a value that increases beyond the maximum, the gauge remains stuck at its
‘mum valu: Ifthe represented value subsequendy fll below the gauge maximum, o
to policies could be adopted:
1, Allow the gauge to decrease so tha the gauge always has the same value asthe
cled value so long asthe modeled value remains in the range ofthe pauge,
2. Leave the gauge stuck at is maximum value une it is reset by management
‘There is no consensus on the correct intepeetation. Thus, the preceding disc
‘latched counters does nor necessarily apply to latched gauges. If the second i
‘ation inthe preceding list is wed, then there is a potential problem of multiple
being allowed 10 reset the gauge, as discussed fr latched counters. One positive fea
‘of using the second interpretation in the preceding ies that if the latched valu is
immediately rset, it tells managemene stacions tha some paranieter has been
(for example, maximum queue se).
The tineticka type ia relative timer: Time is measured relative co some e
(such a8 stareup or renitialization) within the managed system. While such values
‘unarnbiguous withi che managed syst, they cannot be diecly compared to timer
‘es in other systems. Some designers would have preferred an absolute time value
the standard ASNA1 representation. Unfortunately, most systems running, the
protocol suite do-not support a time synchronization protocol. Thus, an absolute
‘ype is impractal for SNMP,
‘One important type that islet out ofthe SNMP SMI isthe threshold type. A
fs used in the following way: Ifthe theeshold vale is crossed in either a postive oe
dlirction, depending onthe definition of the threshold, an event is trggered ancl an
‘sent wo the management sation). The SMI designers feared that this
bility could ead eo event floods, in which a managed syst’scheesbold is repeat
‘rosie and the system floods the nerwork with numerous event notifications, Sack
floods have been experienced on ARPANET and other networks. A pasticularly deadly
‘of evene flood is cme in which the even i triggered by congestion. The creation ofan
‘ood due to congestion exacerbates the condition beng ecported! Howeves, we wile
the Remote Monitoring (RMON) MIB defines a form of threshold (Chapeer 9.
Defining Objects
‘A management informacion base consists ofa set of objects: Each object has a type
value. The object type defines a purticlar kiad of mannged object. The definition of
object type is therefore a syntactic dscziption. An object instance isa particu
pe that has been bound eoa specific value. How are we to define obecs for inclusion inthe MIB? The notation that wal be wsed
‘ASN.1, As explained in Appendix B, ASN.1 includes a number of predefined universal
‘ypesand a grammar fr defining new types that are derived from existing types. One ake
nutve for defining managed objects would be to define a new type called cb je==. Then,
every object in the MIB wwould be of ths type. Ths approach is technically posible, but
‘would resale in unwieldy defnions. We nea to allow foc 2 variety of value types, includ
ing counters, gauges, and so forth. In addition, the MIB suppor the definition of rwo-
dimensional tables, o arrays of values. Thus a general-purpose object rype would have to
samehow include parameters that encompass ll of these posible and alternatives.
Recause managed objects may contain a variety of information to representa vari
ry of entities being managed, it makes more sense wo define an open-ended set of new
types ome foreach general category of managed object. This could be done ares in
ASN.1. Howeres this alternative also has a drawback. Ifthe only retction on the def
nition ofa new managed object type is tha the definition be written in ASN.1, we can
texpect to se considerable variation in the format of object definitions. Ths variety will
make it more difficult forthe user ot implemeator of a MIB to incorporate a variety of,
‘object types, More seriously, the use of relatively unstructured object type definitions
‘complicates the tsk of using SNMP for interoperable acces to managed objects.
"A more attractive alternative, and the ane used with SNMR isto use a macro to de-
fine a set of related types wed to define managed objets. As explained in Appendix B 2
macro definition gives the syntax of set of relaed types, while a macro instance defines
a specific type. Ths we have the following levels of definition:
1 Macro definition: defines the legal macro instances; specifies the syntax of a set of
‘elated types
+ Macro instances an instance generated from a specific macro definition by supplying
“arguments forthe parameters inthe macro definition; specifies a particular type
1 Macro inctance ve: represents a specific enticy wid a specific value
The macro used forthe SNMP MIBs was initially defined in REC 1155 (Strucare of
‘Management Information} and later expanded in RFC 1212 (Concise MIB Definitions)
‘The RFC 1155 version is used for defining objects in MIB The RFC 1212 version,
‘which includes more information, i used for defining objects in MIB and other recent
additions tothe MIB.
Figure 5.3 is the definition ofthe ORJECT-TYEE| macro from RFC 1212. The ey
components are as follows:
+ SMTA: the abstract syntax forthe object type. This most resolve to an instance of
she Oo fect Syntax type defined in REC 1155 {se Figure 54), Essentially, che syntax.
Sel ano so mi MI Pcs ane 95 SNMP MANAGENENTINNORNATION
FEDS chjacttn, objet Gyatax FAN ERTS BE
SECT TYER YARD 2
asa
SMITA ype (TIPE Objec syntax)
sncoss
ssmamis Seatus
SeferPert
IndexPare
DefialPare
AOE HETATECN <= vale’ (FALIE Object)
ad-onlp| “read weiner
i [Mnot-accenei ble
nsndacary|aptions:*|*obanlore® deprecated
Bonet Fars
"URSCKCETIW value (deacei pion Displaysesing) |eapy
Referee = HEFERENEE™ Vale Cr
THEE *1" rndextypes *)*
Indeatypelodextypen ".* Tndexype
imlectype s+ yezue (Indenobject Objecttne) if indexobect, use the SMMTAK
‘ale of tie cortespedent
SORE THE aponeaton
tops (andextype) ‘thancise use named SHE types
ssuust conform =o Tadersyntan
epleyStetng) [oupey
Andecrare
Emlentyeos =
DoP¥alBact {i= HVALY =|" value (énfemive ObjectSyntax) *)* leupry
Dhepimvsering <= OBEY SIRIE SIPS (0,.255)
ledeaSyotan se CRDICE ¢ muabes STEGER £0,.0AX)
crite Gos ScHING,
ject Ouecr coamtET,
‘sisress Metwociiddceas.
TpAddecss Sphdcreas
FIGURE 5.3 Maceo for managed objets (RPC 1212) ry, suit. experinenssl, pLvate, enterpetees, OBIECT-TYPE,
Gofectiace, Chfecttyacan, ‘Sixplasyacar. spplseationSyntex, Werk Addee
iddesa, Counter, Gauge, TEoeTicks, Opec
to the soot
it amuse TamTIeR = 8 GRA) doe(o) 27
ery ‘OAIRST IDEXTIPIER == { nternee 1)
OMIBCT TDONTIFINR :o= | smternet 2 |
cimcal —OGIRCT IDENIURTER == {internet 9)
ce CObSCT SDAWTIEIER so ( dntecuet & |
risen OBJECT IDRNUTHTER ::° ( privare 1 1
Gefinivica of object types
rn C80 =
eyntt type CE Chfeersyntus)
aceesse Acces
sseanice ‘Seatue
IKI NOFATICN i= vasa VALUE Objections)
Jocese 1 = *tend-oniye|tread-urlea” ewetseonly*[*aot-acceasible
Scarce :o= “aunvory”|"epttonal*|obrolete®
tunes of objects in the HIB
rex $1% GOIGE (winple Sinptesyrcax,
nove: that single SOQUENCES are noe Uieectly nentlooad here t0-heep things
‘lapte (ivers Deevert misuae) Boweves, appiicactonwide type whic re
Stepicertsy excnded ainple SOMENC=e axy appear in the folowing CHOICE
on ida Appin
ont
CORES (mbes, TRE,
‘steing OIE: STRING
ject OBIPCT ERTIETER
fengry YL
5.4. Structur of management information (RFC 1155) 96 SMP MANAGEMENT INFORMATION
Inpltcatlonsymei i= GWE “addcean
eee
Heke Haericks,
arbitcery Opaque
Htcacion wide typos, a6 they are defined, will be added be
Networdhldseas ::7 Giee [dstemnet Ipiddess)
{padicewa sm (apeLacanzen 91
DELICTY ocx sTRite (S124 (4))
etworkcbyte ocder
Sees = (ARMLZCATION 1] ELIOT oeseA (496067295)
Gwoge #:> [APPLICATION 2] THPLIGIT mes (0. 4296967295)
‘Teeth j= (Arectcanio8 3) eLtcrY merecam (04294967265)
Sragoe :o= TARRLICATZON 4} COMET STRING vachstraty ASA value, dosble-weap
=p
FIGURE $4 Structure of management information (RFC 1158) Continued
‘tut be constructed using the universal and application-wie types allowed in
‘quired for tha object type. Implementation-pecific additions ot restrictions to
‘access are permissible. The options are read-only, read-crite, write-onty, and
«accessible. tn the later ease, the object's value may nor be read and may aot be
* STATUS: Indicates the implementation support required for this object. Sup
‘tay be mandatory or optional. Aematively, an object can be specified as
cated. deprecated objects one that must be supported bu that wil mos likely
ssmoved from the next version of the MIB. Finally, the status may be
‘which means that managed systems need no longer implement this object.
‘+ Beocr2art: a textual description ofthe semantics ofthe objet type. This laure ‘Sint of Management Information 97
‘+ IrdoxPares ued in defining tables This clause may be present only if the objoce
«ype corresponds toa conceptual row. The use ofthis clauses dseribed later in this
chapter.
+ Dotva1Part: defines an acceptable default value that may be used when an object
‘instance ie created, atthe discretion ofthe agent. This clanse is optional
‘VALLE NOTATION: This indicates the name used to acces this object via SNMP.
Figure 5.5 shows an example of an object eype definition
‘Because che complete definition of the MIB using the CEECT TYP maceo is coa-
tained in the MIB documents, and because of te length of such definitions, we wil gen-
erally refrain from their use, stead we will we a more compact representation, based
‘on te structures and a tabular presentation of object characteristic, as willbe seen
ahead
Defining Tables
‘The SMI supports only one form of scructuring of data 2 simple two-dimensional rable
with scalar-valued entries. The definition of tables involves the use of the aacuence and
‘eequenca-of ASN.L types and the InéexPart ofthe O3#CT-TYFE macro.
‘The best way to explain the rable-efinition convention i by example. Consider the
object type tepCanr:Table, which, as was mentioned earlier, has the object identifier
1,36.1.2:1.6.13, This object, the TCP Connection Table cootans information about
‘TCP connections maintained by the corresponding managed entity. For each such con-
‘ecsin, the following information is stored in he eable-
‘+ State: che sae ofthe TCP connection [The vale ofthis entry may be one ofthe 11
“TCP states as defined inthe standard (sce Appendix SA co this chaprer); the vac is
ser bythe TCP entity and is changed bythe TCP eniy to eet the state ofthe con-
‘nection. In addition, the entry may rake onthe value Aelet e703; this sa value ser “SP MANAGEAENT INFORMATION
bby a management station. When this value is st, it causes the TCP entity to
the transmission control block for this connection, thereby destroying the
‘toa; this equivalent toa transition to the CLOSED sat.)
‘Local adress: be WP adress ofthis end ofthe connection
* Local port: the TCP port ofthis end ofthe connection
‘+ Remote address:the UP addres of the oer end ofthe connection
++ Remote por: the TCP por ofthe other end ofthe connection
Before proceeding, itis instructive to nore char the TCP connection table isa
the MIB and, as such, s maintained by a managed sation to provide visibility 0
‘management station of some underlying entity represented bythe managed object In
‘ase, each entry in tepCeneTable represents the state information stored in the
ged station for one connection. As indicated in Appendix SA, this state infor
‘consists of 22 separate items of information foreach conection, Only five of these
are actualy visible to network management by means ofthe <
sepa te Sees |
ast rome ons
11 pny “SIND ty gy pry paodamaly QOH |W
seo ‘
snap wma
re om regener
ope food
“ans ese coe
1 mapa emmy wor ae gE NOMS
I A
se) Sen ae
Tre6t Sn) Aawos3yic} eno} SY SPN AINNS L's STEVE
3 EARS MTP AN
caer ye So pie pa ype pei 7 moe me QOL APE] my
“pe Ae
popmepace px ped pamurg emmy aes RNS 19 eo Pa een wpa peparm a ee Ears ono NS 2
Ta tiapan yan aap mad sey = PN cme an Ne PPR GIF A ECOL OS re STAN
"ef sey sacs oe nga 30)
epee sm py one at tin pun eae eon mae Pa ae FS EV
EELS SG REEL Tp Se eis opr sang oom oped OL AB NYT mt 2S we
Se bane ond par Waren mo miowroo ay EEE TaN? mvs MBO
was PTY
mes
saopes ome ped
poor uo ans £00 aan #08
‘or 3000 Saitos Sp Sova 006"T
ry sy Seopa amg anddemety (yo eager betty Ong
oa
coped apes weed
psi od sans 4 anys
Soma ‘oom is ‘Somos pea o0s"t
° img “msscwety —}o 7am eddety NOT
105 poop 1
ome a oe
© E661 UN) Sur AST IEF FO MINED AHBY GANS MON STEVE san png emo go tam gyn ype ned eo ped wpe ui THs 8 on
‘ros 0)» 8 eta 2 9) ee 8
rags ame MET to USE ee el a
mpeg
0
oo
og
woes
ol
wou
ap
gpa eeieeneneenenmnmnntesessabiiniaisienia =e
banal: 'ules- anil hinain bheuldehimonaiesdacmeretione ee ee eed
Seni ina vena ops i rp pe peat nor perma moped mona Nee,
asa deine Foo AMPA aD Sy aE ApoE. eee
pone
od ee panes 1
opener spon $s soliton g voy ute 5
pause
esp ‘8 snes
28S RAT semi? © gt ahi (acme ge
ssp axqoussmer pp sense au
lnc 0 meg sey ae
oun
se eaygaad woe 0 501
‘eso sno ey 08 cca werden og poy mam egg
PE 26S ken ee “AS pe eames alle
ts
ove soem
‘mp eigen vopes sare ve ma
‘wo toma e505 or amas, “4 ammammuey ogg
prunes
yo sas es pam
FD SEN AE SAN ee oe ge ae a
ownoo
oyporg —— Aatamor SO, 0s ee aeRO ER
Si a ap
mane Smet ares
(21661 SOR auML aeRO EY NEMO es nave SB Procct hanee 108
Ain, atest was conducted using objet from the Interacts groups cs from the IP
roap were ako incleded. The tes ream consisted of 245 packets broken down as follows.
+ 120 packets contained IP datagrams withthe unicast MAC addees ofthe router of
which
~ 40 contained the router's IP addeess
= 45 contained distant IP addeess witha 0 time-ro-ves
~ Scontained an invalid IP address
30 contained a valid distant IP address and a nonzero time-tosve.
‘65 packers contained a broadcast MAC address that inched the router and that
should have een delivered o a higher layer within ehe router
25 packets had am invalid protocol rype in the Etherter header.
£35 packets had an incorrect frame check sequence,
“Table 5.2 shows the eesults for some ofthe counters in che Interfaces group. Noe a
Single vendor reported accurate values for al ive counters. Table $.3 shows the results
for counter in the IP groups again, not one yendor got all of the numbers right. In a few
‘2sc, itis possible chac the fault is not with the SNMP agent sofeware but with the enti
ties being managed. For example, five ofthe rowers failed to report datagrams that had
‘expired. Ths could be either because che agent failed to count datagrams that were ds
arded because they expired or because the IP enety forwarded expired datagras. la the
laces case, the SNMP apent isa useful roo! for detecting aul in other software,
‘The resls ofall of these tests re clearly cause for concern. These sates are cit
cal tothe network manage. For example, fa rourer agent fails to report the presence of
‘errored packets, then a serious condition threatening che neework could remain vnno-
‘iced uni a catastrophic fake occurs
‘Compared tothe OSI network management scheme, SNMP sscrifices funtionalcy
for simplicity: One of the strengths of the SNMP standards is thee relative clarity and
succinctnes. Yet, despite this emphasis on simplicity, products from reputable, well-
‘established vendors eannor agre:on some of the most basic parameters that a network
rmaragement system must measure, Several cautionary observations can be made,
1. There i aneed for some sort of verilicaion or cerification procedure for SNMP!
‘MIB to increase che likelihood that vendor offerings are “coer.”
2. Im the absence of such certification, th customerlusernceds to know chat, like aay
‘other pice of sofeware, SNMP manager-agentsofrwafe may contain exors:
“Te eon pte nthe hed ed peer atari fom emg i clo ee
ils Fach ene spp a dcement hu prof owas atm an xc ee
‘Ndnoutn witha owen woe al tt sO is de, strom pnd 110
5.22
SNMP MANAGER INFORMATION
3 bese are the problems one faces withthe relaively simple SNMP, one can
‘the potential for msinformation and miscontrol in OSI nerwork management,
Private MIBs
‘One of che strengths of the SNMP approach isthe way in which the MIB.
designed to accommodate growth and to provide flexibility for adding new
as mentioned, private extensions can be added tothe private subtree (Figure $1
allows sendors to create objects to manage specific entities on thet produces
‘make chose objects sible to a management station. Because ofthe use ofa
SM and a standardized object identifier scheme, it should be possible to manage
‘objects fom a management station of diferent vendor. In other words, nseope
should extend to private extensions tothe MIB.
‘With SNMF, a management station can access only the information for
‘knows how ta ask. Recall that chis approach was taken inthe design of SNMP ea
the network from being clogged with management information that devices were
less broadcasting, Thus in order for a managenient station to beable to manage
MIB object, the management station must be loaded with the private MIB
Otherwise, the management station cannot offer the user the benefits of those
extensions. Of course, loading the private MIB into the mansgement sation
Sent problem if the management station and the agent station are from the
‘dot. The potential for difficuly arises when the two are from diferene vendors,
‘Most vendors supply both a text version and a formal descrgvion of thie
‘extensions. Wichout the formal descriptoa, it would be necessary to type many
hundreds) object definitions into the management station. With a formal descip
‘management station should be able to read a MIB fle from disk and compile ii
‘management station’ ibeary of managed objects. One dilfialry that occurs
dors currenely use chee different formats to define private MIB
* The orginal SNMP SMI specification, REC 1155
+ The newer Concise MIB Format, RFC 1212
+ The OSISMI speciation
Converting fom one MIB to another is currently a manual process that
person to be knowledgeable in both formars and to have hows of time available.
1212 provides guidelines in “de osfring” OSI MTBs co the SNMP MIB formar;
seribes the process as “suaightforward though tedious:
‘Rory in lc foe dering certain pera for OSE
sida bec oe cake. wine speed sora som fr Oil meen
‘ycben devciped, hr to be onhonsog whe mage tandode bie Proce time 111
Tess likly that vendoes using the SNMP format will ll sooner or later comer from
RFC 1155 to RFC 1212. Also, an experience base in converting herween OSI SMI and
‘SNMP SMT is gradually accumulating But another problem isi the actual parsing and
‘compiling of « MIB specification. Despite the face thae MIB object are defined using for
nal techniques, different management syaterns seem vo apply diferent criteria in deter
mining whether a vendor’ private MID i syntactically covet.
For a concrete example ofthese dificult, we again turn tothe Bell Labs studies of
Ioridges and routers, reported in Table 5.4. Again, the results are discouraging to the
ustomestuser who Believes the “sznple” in “SNMP” Inthe cae of the bridge product,
half of che products equipped with private MIBs produced mj problems. In all cases
ofboth bridge and router products, the process was less than smooth,
‘Ngnin, the conelusions to be drawa from all ofthese testis that one should he wary
of using private SNMP extensions and cha greater problems await in OSL systems man-
tgement. With SNMP, users need to determine how much ofthe control of SNMP agen
product bas been embedded in propritary MIB objects and make sure that the man-
fgement station they are considering can accommiodate such obocts.
Limitations of MIB Objects
[A nerork management system is limited by the capabilities ofthe neework management
protocol and by the objects used ro represen che environment to be managed. la Chap-
fer 7, we examine some ofthe key limitation of SNMP. These limitations are "funda-
‘mental,” in the sense thatthe limitations cannoe be removed without changing the SNMP
specification and subsequently all ofthe SNMP implementations ia « configuration
“The limitations due to an inadequate set of objects in the MIB are les serious, These
‘can be dealt with by adding more objects. Howeves itis tl erue thatthe implementa
tions in 2 configuration, including boch manager and agent, aust be enbanced to deal
With che new objects, In any case, the standard MIBLT serves as a common base for all
limpermencations, and itis important to recognize that MIB- Il does indeed limit the abil-
ity to mouitor and contro a network,
‘Wegive one example here, suggested by Masum Hasan at che University of Toronso’s
‘Computer Systems Research Institute. The example makes use ofthe configuration in Fig
tte 5.8, Suppose that cher i substantial traffic ta the serve from throughout the net-
‘work, causing a considerable land on outer R2 and subnetwork NS, but thatthe router
and network are able to handle this load. Now suppose that anew source of tac deve
‘ops herwen systems on subnetwork NS and subnetwork N4. This may increase the load
fon R2 or N3 to unacceprahle levels. IF could determine that tis increased lod isin
fact caused by addtional NS-N4 eralfc, we might beable ro design effcetive eountermea-
sures, soch as anew bridge or router linking N4 and N6. However, there is no way to
determine this sing MIB objecs. For example, if we could examine TP telfic on 3
pesconnection basis, then we could examine the trafic on connections rerminating ac N3 STN TRS SIN moe me DS ORLA A A Ha A Sm pT NT
“oe ayes ie fonds pox dha ke ys Bor a
{erm PP St I Som pe mts ies em ura Nop eCopt
ep ppd veer Race Fama
Pe pra pan sooo a,
13193030 200 oe ae a,
100 kg ooncep
fonnoqp cto oot Seon,
stung eee pas teres
xf 14 a0 Moye AYE A,
“mp pa ppt pe
Poy pata sai ng apse,
10 Aga sep
Tei 94200 Pe) Keen ULAOpeOOEE) |
ou Ay sop
‘Peemuiaen m| 200 pen) spamayan 0 proj erI
moe TWN 9870) anaes
senor dpuganijury poe puncy em soul seis
‘oqo new yao Jour suman og aye oek
“ou ys ue 4
Peamnnp 9204 pyaar oo PTL]
Ip pos pmo pus aay yeu sn xu 30)
Poem pm seo apne mates y
ate WN
32294 mre 7 ug am yeh are por Span
-Bguesenoqgemn anon cry gogo ae
9 papauant
Pur paso par saGo'59, sano soem ST Ok
“opaesiyn ‘smagede> pana
suon any MRF] MG a ogee
eo
Dgpadiopees pe oF
‘(e166t WW) sampaag apg (e)
Dnguatwey Ste nsy UN ws TEV ns
Tale en
‘gees 300 pur ure ig psmbs Rute ny “ans 204 pub soi
go dled aon m9} ey, Joona says hae fry BO, hea mon ay 8, ator sy wom,
= “ep pocs pape
Pad papuoid por popiom ‘im -pombovazam sown oad pan payne St safeom so a
‘Supe ‘pas aio ge Ramsey Moge ayes, papal NGO EOL apo UNoG om ne SY g
‘uonemiioo ao 089 ‘ptroes—wgemdyuo yo neg “pasts
39 agiammmra ao OO 44 pombes up ay ‘aseroee saa sage yous eat ooh
mow sanog ow wR Jom sie aku Ff wo oy somMETSAimoy Seek GM Seu OT MoE ah
“pment “paurtos poor moo ye "pombas sims
sp a 0 mom 2) au 3 oO EL ou Jo nou oj ae fg) oun Kes oom hues
prin som sng ON, Sermo oun nOge my HA PRIMES NNIL ANN SOG aa ORT SHEL
ame
‘nie gs 100 pa sauna fg pa -ayws 200 pat sso
sew Iv a ou oj AQ oy Typo seung soa eso, ghatead Sn may adn 1 00 apy
ambos a
‘arp post poptinsd —poxbas asim winsano9 xeuis “np pod pope por “immo rad soe
PE paiom pow mig Joe. ong smo Ene SUR SX Rpm NED IOI HEA oA Hea Rg
‘sag 00 {peg 00 cs sete sem
go suun-pen ng ‘pros esp 20) aad
sonar posta ay Ԥ deme sy 00 Rou post ay 205 rome say 924
2p po “PE pom ay 20 “rp poo pop. uve
Porson por peyson tom poouinn aj opey gy 3049 put poy ems yoy wy Ripe
Sepepa‘pmn smsk pee ado] + toy veInOGE ae K—-peul pa ENGD eA aoe May OR
{ego feoner Tear IO mI {se ENN UAIER= eTA SoRA
san ard parses sore “aypelianpest profes gy IW swmud pope score ayuednampens proj Sey stout
PAPA oI A PrN ange Bre eg,
oe ARH, COP ns MaRTETENY X PER
(a1664 19) sonoma Ne (a)
Pomusucy ws arava 53
14
[SNMP MANAGEMENT INFORMATION
eof here is clear: A finergraned set of MIB object allows for
iol of the network. The costs ar increased storage and pracestigg eae
increased SNMP trafic over the network: MIB-tLie
ligt mine te
f7senand never, whch fn Howe te oe oe
Nopng wx venge
Summary
Whi the SNMP famework, ‘The structure of management information (SML) defines che allowable ASN.1 types
the allowable MIB structures. Most objects ate scalars the allowable types are
er, octet string, null, and object idencifier. The cequence and
‘60-8 types may be used ro construct simple two-dimensional tables of salar
. No more elaborate siructuce is allowed. 116 sup asnuicemenr NPORMATION
ENP CONNECTION STATES
Tn this chaper, and in Chaprer 7, the object xepConucTable is wed as an examy
instructive o look at the underlying protocol information reflected in this,
object. This appendix coneins a brief summary, For ate deal, ce Stallings (
the actual TCP standard
Since TCP is designed to run over an unreliable nerwock service (specifi
‘must contain elaborate mechanisens to deal with lost, duplicated sisordered, and
‘segments. One ofthese mechanisms defines the procedure for connection esta
1. ATCP catty initiates a connection establishment by sending a Yt the
2, The other side responds with a SY, ACK sequence.
3, The initiating TCP enticy acknowledges the $1\/ 0K with an ACK.
The Sut represents a request for connection, or a willingness to open a cont
With the procedure just outlined, each side explicitly acknowledges the och
‘This procedure is known asa three-way handshake and prevents a numberof
that could arise ifacwosway handshake (SYN followed by ACH) were used,
It could happen thac wo TCP entices issue a SYN co each other at about
time, This is allowed, and a connection results. The sequence listed ear ia
follows:
1. ACP entity initiates a connection establishment by sending a Sitio the
2 The TCP entity ceceives a SYN from the other side.
3, The TCP entity acknowledges the SEN with a SY, AK
4. The TCP entity receives an ACK from the other side.
A similar duee-way handshake is used to close a connection, All ofthese
bbe modeled by a state transiion diagram. Figuce 59, taken from MIL STD.1778,
the TCP scat transition diagram. The upper par ofthe label on each state
shows the input tothe TCP entity, which is ether TCP segment from another
4 service request from a wer af this TCP enti, The lower part shows the TCP se
‘issued by this TCP entity.
‘Gr one ef gcc dat emer TH th TCP spent: Wh he dard est
1 Swans the sg ny lens TCP ager whe ithe het ai ‘Arpendic SA TCP Comecion Soe 117
or acne npc pv per en
a [fay specta pase op
nen 5
sew
Bscske Fo, ack osm
Send hoe
ste ‘ona .
sae
cove
sear
Tomeout_
aus)
5.9 TCP emity sete summary (MIL-STD-1778)
{To maintain various connections, a TCP enc retains state information about each
connection, in whac is referred to as 8 state vector (MIL-STD-1778) or a transmission
‘control block (RFC 793) The state vector includes the following information:
‘+ state: one ofthe sates ofthe connection
srca_addrese: IP address ofthis systema ‘> source port: port mumber of the TCP user at this end ofthe connection:
‘+ deetSnas ton address: IP address ofthe gstem at che other end ofthe
*+ Len: local connection name; shorthand identifier used in service request
sponse interaction with the TCP user to eefer to this connection
* sec: security label fr this connection
‘+ sec_ranges: security structure that specifies the allowed ranges for this.
‘+ ordgsnal_prect prictdence level specified by the local TCP use in the open
1 Actual pee: prsedenc vel negated at coneton opening ad
* ULP_
